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SUBJECT:  Major  Autoaated  Information  System  Review  Council 
(MAISRC)  Guidelines  for  Program  Managers 


Consistent  with  our  agreed  upon  initiatives  for 
strengthening  the  Department's  management  of  ADP,  I  asked  the 
OSD  staff  to  develop  a  document  for  ADP  program  managers  which 
provides  further  insight  into  our  OSD  ADP  oversight  review 
process. 


The  enclosed  document  has  been  developed  with  the  input 
and  support  of  many  OSD  staff  offices,  especially  the 
Directorate  of  Acquisition  and  Logistics  Information  Systems. 
I  trust  that  these  guidelines  will  be  helpful  to  your  ADP 
program  managers.  Further,  I  believe  that  this  document  will 
help  reduce  the  time  and  effort  required  by  all  our  staffs  in 
preparing  and  efficiently  executing  future  MAISRC  reviews. 
However,  you  should  remember  that  these  are  guidelines  and 
should  be  applied  with  good  judgment. 

Please  ensure  that  distribution  of  these  guidelines  is 
made  to  ADP  program  managers,  your  ADP  staff  and  other 
appropriate  personnel.  Additional  copies  will  be  made 
available  through  the  Defense  Technical  Information  Center 
(DTIC) .  If  you  have  any  questions  on  this  document,  please 
direct  them  to  Mr.  Harry  E.  Pontius,  of  my  Directorate  for 
Information  Resources  Management  Systems,  on  697-6954. 
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FOREWORD 


k 

The  Major  Automated  Information  System  Review  Council  (MAISRC)  serves  as  the 
Department  of  Defense  (DoD)  senior  management  decision-making  body  for  Automated 
Information  Systems  (AIS).  This  process  needs  to  be  understood  by  AIS  Program 
Managers  and  component  staffs  in  order  for  the  MAISRC  to  complement  our  Life  Cycle 
Management  (LCM)  policies  set  forth  in  Department  of  Defense  Directive  (DoDD)  7920.1 
and  Department  of  Defense  Instruction  (DoDI)  7920.2.  Therefore,  the  Office  of  the 
Secretary  of  Defense  (OSD)  staff  has  prepared  these  MAISRC  Guidelines  for  Program 
Managers'  use  and  understanding.  The  Guidelines  explain  the  who,  what,  when,  where, 
and  why  of  the  MAISRC  process. 

The  information  presented  should  assist  a  Program  Manager  in  better  understanding 
and  preparing  for  a  MAISRC  review,  h  has  been  our  experience  that  well-structured, 
managed,  and  documented  programs  usually  require  little  additional  preparation  for  a 
review  by  the  MAISRC.  So,  a  program  that  does  not  adequately  possess  these  qualities 
and  adhere  to  the  principles  of  LCM  may  encounter  difficulties  in  preparing  for  and 
obtaining  a  successful  milestone  review.  These  Guidelines  should  help  preclude  the  latter 
case. 

V  ^ 

It  is  recognized  that  program  management  and  development  is  not  a  precise  science 
and  tailoring  must  occur.  Therefore,  the  MAISRC  management  process  has  provisions  to 
adapt  these  Guidelines  to  the  specific  nature  of  the  program  under  review. 
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CHAPTER  ONE 
INTRODUCTION 


1.0  PURPOSE 

This  Guideline  provides  Program  Managers  with  information  about  the  Office  of  the 
Secretary  of  Defense  (OSD)  Automatic  Data  Processing  (ADP)  review  process,  focusing 
on  preparation  techniques  and  product  formats  required  for  an  effective  presentation.  Its 
intent  is  to  amplify  Department  of  Defense  Directive  (DoDD)  7920.1  and  Department  of 
Defense  Instruction  (DoDI)  7920.2  by  describing  the  details  of  the  review  process,  the 
composition  and  roles  of  the  Major  Automated  Information  System  Review  Council 
(MAISRC),  and  issues  that  should  be  addressed  to  prepare  for  a  successful  review. 

The  MAISRC  is  not  an  end  in  itself.  In  simple  terms,  this  senior  DoD  council  is 
charged  with  looking  at  major  resource  investments  in  general  purpose  ADP  systems  at 
critical  points  in  the  development  cycle.  It  is  an  active  decision-making  body  —  one  that 
must  issue  a  “GO”  or  “NO  GO”  on  the  basis  of  the  facts  presented  before  it. 
Accordingly,  the  council  will  want  to  review  certain  documentation  to  formulate  their 
opinions.  These  documents  consist  of  normal  planning  and  control  type  documents 
usually  required  during  system  development  by  the  prudent  manager.  Their  presentation 
before  the  council  should  therefore  pose  little  additional  burden  to  the  Program  Managers 
(PM). 

Past  experience  has  shown  that  the  MAISRC  review  can  be  more  effective  if  the  PM 
is  provided  with  the  right  tools  and  assistance.  This  has  been  demonstrated  by  the  steady 
improvement  of  both  techniques  and  presentation  formats  of  individual  PMs  with  each 
subsequent  appearance  before  the  review  council.  The  PM  can  better  prepare  for  review 
after  learning  what  the  MAISRC  does,  how  it  operates,  and  what  the  PM’s  responsibilities 
are  before  the  MAISRC.  Therefore,  a  need  exists  to  orient  the  new  PM  on  the  preferred 
techniques  and  formats  so  that  he/she  can  participate  in  the  review  effectively  at  the  onset 
of  the  program,  rather  than  undergo  a  “baptism  of  fire”  to  attain  familiarity  with  the 
process. 

1.1  OBJECTIVES 

The  objectives  of  this  Guideline  are  to: 

•  Provide  an  overview  of  the  MAISRC  review  process  (the  who,  what,  when,  where, 
and  why); 

•  Outline  the  composition  and  responsibilities  of  the  DoD’s  MAISRC; 

•  Encourage  early  and  effective  communication  with  the  DoD  staff  to  assist  in 
review  preparation; 

•  Identify  the  types  of  reviews  a  PM  might  undergo; 
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•  Emphasize  the  need  to  identify  and  address  problems  early  in  the  review  planning 
stages  so  that  they  can  be  resolved  quickly; 

•  Explain  how  the  PM  and  staff  can  prepare  for  a  DoD  review;  and 

•  Provide  references  to  guide  the  PM  through  Life  Cycle  Management  (LCM). 

1.2  SCOPE 

This  Guideline  provides  assistance  to  the  PM  in  preparing  for  the  decision  briefing 
regarding  the  life  cycle  development  of  the  Automated  Information  System  (AIS). 
Although  there  are  two  categories  of  reviews,  a  milestone  review  and  an  in-process 
review,  this  Guideline  primarily  focuses  on  the  milestone  review. 

1.3  ORGANIZATION  AND  USE  OF  GUIDELINE 

The  contents  of  this  volume  are  designed  to  point  out  to  the  PM  those  critical  factors 
that  must  be  addressed  in  each  phase  of  development.  While  it  is  not  all  inclusive,  it  does 
discuss  the  most  common  areas  of  concern  in  typical  life  cycle  development. 

In  addition  to  this  introductory  chapter,  there  are  four  other  chapters  in  this 
Guideline.  Chapter  Two,  “The  MAISRC,”  describes  the  the  purpose  of  MAISRC  and  the 
roles  of  its  members  and  supporting  staff.  The  chapter  discusses  the  multi-phased  LCM 
approach  to  administering  the  major  AIS,  and  identifies  the  major  decision  points  where 
decision  briefings  are  required  of  the  PM. 

Chapter  Three,  “Dynamics  of  the  MAISRC,”  combines  the  LCM  and  MAISRC 
processes  and  describes  the  preparation,  conduct,  and  post-conduct  stages  of  the 
milestone  reviews. 


Chapter  Four,  “Questions  to  be  Answered,”  details  specific  questions  the  PM  and 
staff  should  be  prepared  to  address  at  each  milestone  to  ensure  the  quality  of  the  program 
and  to  support  the  MAISRC  decision. 

Chapter  Five,  “The  Program  Manager,”  provides  a  brief  primer  on  the  PM 
appointment  process  and  the  features  of  a  typical  PM  charter. 

The  PM  and  key  members  of  the  PM’s  staff  should  review  this  volume  in  detail  to 
become  thoroughly  familiar  with  the  milestone  review  process.  Additionally,  Section  2.3 
and  Chapter  Four  should  be  periodically  scrutinized  for  those  phases  of  the  life  cycle 
which  the  program  is  undergoing.  These  sections  will  be  of  assistance  in  the  review 
preparation  phase. 
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CHAPTER  TWO 
THE  MAISRC 


2.0  BACKGROUND 

The  fundamental  document  that  establishes  major  system  acquisition  policies  for  all 
of  die  governmental  agencies  is  the  Office  of  Management  and  Budget  (OMB)  Circular 
A- 109,  which  identifies  key  decisions  and  outlines  the  logical  sequence  of  activities  in  the 
acquisition  process.  The  circular  applies  to  a  wide  variety  of  major  acquisitions  ranging 
from  systems  required  in  production  quantities  and  operated  by  the  Government  to  unique 
or  limited  quantity  systems,  such  as  Automatic  Data  Processing  (ADP)  systems.  The  fun¬ 
damental  management  principles  conveyed  are: 

•  Mission  analysis; 

•  Early  identification  of  mission  needs; 

•  Competitive  exploration  of  alternatives;  and 

•  Key  agency  head  decisions. 

The  Department  of  Defense  (DoD)  implemented  the  principles  of  Circular  A- 109  and 
published  them  in  DoD  Directive  (DoDD)  7920.1,  “Life  Cycle  Management  of  Automated 
Information  Systems  (AIS).”  Included  in  this  directive  are  those  acquisition  principles 
plus  other  processes  that  are  termed  “Life  Cycle  Management.”  Life  Cycle  Management 
(LCM)  can  be  defined  as  the  environment  in  which  the  PM  will  operate;  it  encompasses 
the  time  period  from  the  program’s  inception  to  its  eventual  phase-out  or  replacement  by 
a  newer  system.  It  emphasizes  the  need  for  the  PM  to  develop  and  manage  the  AIS  to 
meet  the  user’s  mission.  LCM  philosophy  and  its  organized  process  are  discussed  in 
Section  2.2. 

2.1  WHY  THE  MAISRC? 

The  use  of  information  technology  has  expanded  throughout  all  areas  of  DoD. 
Consequently,  the  information  technology  budget  has  risen  dramatically.  This  in  turn  has 
resulted  in  the  need  for  structured  management  oversight  and  prudent  fiscal  management 
in  the  acquisition  of  general  purpose  AISs.  It  is  DoD  policy  to  manage  these  acquisitions 
in  a  way  that  promotes  the  efficiency  and  effectiveness  of  those  systems,  and  ensures 
meeting  the  functional  need  while  conserving  resources  necessary  to  procure,  operate, 
and  maintain  them. 

2.1.1  malla-tlie-MAISRC? 

The  senior  DoD  ADP  management  oversight  body  for  major  AISs  is  the  Major  Auto¬ 
mated  Information  System  Review  Council  (MAISRC).  This  council  was  organized  in  the 
late  1970s  to  supervise  the  development  of  multimillion  dollar  AISs.  Members  of  the 
council  act  in  the  name  of  the  Secretary  of  Defense,  and  MAISRC  approval  is  required 
before  a  program  can  advance  beyond  specific  milestones. 


DoD  review  and  approval  procedures  for  a  major  A1S  development  are  contained  in 
DoD  Instruction  (DoDI)  7920.2,  “Major  Automated  Information  Systems  Approval  Proc¬ 
ess."  This  document  specifies  that  OSD  reviews  will  be  conducted  at  four  key  decision 
points,  which  are: 

•  Mission  Analysis/Project  Initiation  (Milestone  0); 

•  Concept  Development  (Milestone  I); 

•  Definition/Design  (Milestone  0);  and 

•  Systems  Development  (Milestone  HI). 

At  these  milestones,  top-level  DoD  management  has  the  opportunity  to  make  critical 
mission  requirement  and  investment  decisions  and  provide  the  Program  Manager  (PM) 
with  clear  direction  and  authority  for  continuing  with  the  development  effort. 

2.12  How  Does  the  MAISRC  Work? 

The  MAISRC  functions  as  a  special  management  review  group  operating  under  the 
authority  of  the  Secretary  of  Defense  with  the  responsibility  to  review  major  automated 
information  systems.  The  procedures  employed  by  the  MAISRC  are  straightforward.  The 
MAISRC  Principals  charge  their  staff  to  develop  an  analytical  opinion  on  the  quality  and 
depth  of  the  development  plans.  The  first  step  is  to  ensure  there  is  a  recognized  functional 
need  or  requirement  to  do  something  better  or  make  a  major  change  to  an  existing 
method.  This  need  must  be  validated  (Milestone  0)  before  the  council  gives  approval  for 
limited  resources  for  an  alternate  design  study.  Once  alternatives  are  analyzed,  tested, 
and  one  is  selected  (Milestone  I),  the  next  major  activity  for  the  MAISRC  is  to  examine 
how  the  PM  plans  to  use  resources  to  meet  the  need.  Rather  than  “second  guess”  the 
program’s  direction,  the  MAISRC  wants  to  ascertain  that  there  is  a  disciplined  systems 
engineering  approach  applied. 

In  1983,  the  Office  of  the  Secretary  of  Defense  (OSD)  streamlined  the  MAISRC 
approval  process  to  allow  for  controlled  decentralization  to  the  military  departments  of 
system  approval  authorities.  However,  for  the  most  part,  the  first  two  decision  points 
(Milestones  0  and  I)  will  be  retained  by  OSD.  The  MAISRC  may  delegate  all  or  some  of 
the  remaining  decision  authority  to  the  DoD  Components.  The  extent  of  delegation  will 
depend  on  the  quality  of  mission  analysis  and  functional  planning,  the  use  of  sound 
management  practices,  and  the  extent  of  competition.  See  ASD(C)  memorandum,  dated 
23  June  1983,  “Revisions  to  Major  Automated  Information  Systems  (AIS)  Approval 
Process”  (Appendix  A).  Other  OSD  delegations  may  occur  as  part  of  che  annual  update 
of  the  list  of  major  automated  information  systems.  This  list  contains  one  enclosure, 
which  identifies  select  systems  that  are  delegated  to  the  Components  for  overall  milestone 
approval  authority. 

2.1.3  When  Docs  the  MAISRC  Take  Action? 

The  MAISRC  is  charged  with  management  oversight  authority  whenever  general  pur¬ 
pose  ADP  systems  (including  those  exempt  by  the  Warner  Amendment)  are  classified  as 
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“major.”  See  Appendix  B,  which  clarifies  this  authority.  The  DoD  has  classified  any  AIS, 
or  revision  of  an  AIS,  as  “major”  when: 

•  Anticipated  acquisition  and  development  life  cycle  costs  exceed  $100  million  from 
the  first  phase  (mission  analysis)  through  the  extension  and  installation  of  the 
developed  AIS  to  all  sites;  or 

•  Estimated  costs  exceed  $25  million  for  a  single  year,  or 

•  OSD  designates  the  AIS  as  “special  interest.” 

The  Secretary  of  Defense  in  turn  has  charged  the  Components  to  design  a  senior 
executive  review  and  approval  process  both  for  major  AIS  programs  delegated  for  Com¬ 
ponent  approval,  and  for  nonmajor  AIS  projects  commensurate  with  the  estimated  cost. 
ASD(C)  memorandum,  dated  13  August  1981,  “Automated  Information  Systems  Covered 
by  Life  Cycle  Management  Policies,”  explains  the  relationship  with  life  cycle  management 
and  is  included  in  Appendix  C. 

The  House  Appropriation  Report  for  fiscal  year  1986  provided  more  specific  guidance 
to  the  Components  in  the  discharge  of  their  oversight  responsibilities  for  those  programs 
delegated  by  OSD.  Accordingly,  ASD(C)  memorandum,  dated  26  March  1986,  “Manage¬ 
ment  of  General  Purpose  Automatic  Data  Processing  (ADP)  Systems”  (Appendix  D), 
stated  each  Component  “should  have  an  accountable,  executive  level  review  process  in 
place  and  operating  which  includes  full  involvement  of  ADP,  telecommunications,  and 
functional  management”  based  on  the  principles  of  DoDD  7920.1.  The  report  further 
directed  OSD  to  establish  firm  criteria  for  determining  conditions  wherein  delegation 
should  be  revoked. 

On  2  April  1986,  the  DoD  Comptroller  disseminated  the  revocation  criteria  as  tasked 
by  the  House  Appropriation  Committee.  See  Appendix  E  for  this  memorandum.  These 
seven  criteria  are: 

•  Program  cost  growth  of  25%  or  more  has  developed  for  the  overall  program; 

•  Program  schedule  slippage  of  6  months  or  more  has  developed  for  the  overall 
program; 

•  The  headquarters  executive  level  review  process  is  inadequate; 

•  Available  program  funding  is  significantly  below  approved  program  requirements, 
making  the  approved  program  unexecutable; 

•  Significant  problems  have  developed  in  the  execution  of  acquisition  strategy  and 
associated  procurement  actions; 

•  Program  planning  or  execution  conflicts  with  established  DoD  policy;  and 

•  Other  significant  issues  have  developed  that  remain  unresolved  and  jeopardize  the 
success  of  the  program. 
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Thus,  the  MAISRC  is  directly  or  indirectly  involved  with  all  major  AIS  developments. 
As  the  primary  oversight  body  it  conducts  periodic  milestone  reviews  where  it  approves, 
redirects,  or  recommends  cancellation  of  the  program.  If  oversight  authority  has  been 
delegated,  the  MAISRC  assumes  a  secondary,  but  not  a  passive  role.  It  is  still  expected  to 
keep  abreast  of  the  development  activities,  which  it  normally  does  through  coordination 
with  the  Components  and  receiving  “in-process”  type  reviews.  (For  a  discussion  of  types 
of  reviews  see  Section  3.2.) 


2.1.4  fflm  Sits  .On  titt.MAlSRC? 


DoDI  7920.2  outlines  the  membership  of  the  MAISRC.  Additional  members  were 
added  as  described  in  ASD(C)  memorandum,  dated  9  November  1984,  “Designation  of 
Principals  for  Major  Automated  Information  Systems  Review  Council  (MAISRC)  Decision 
Meetings”  (see  Appendix  F)  and  ASD(C)  memorandum,  dated  23  June  1986,  “Independ¬ 
ent  Reviews  to  Support  the  Major  Automated  Information  System  Review  Council 
(MAISRC)  Reviews”  (see  Appendix  O). 

The  MAISRC  meets  as  needed  and  its  composition  is  tailored  according  to  the  level  of 
review,  service,  interest,  and  the  type  of  function  being  supported  by  the  system. 

The  Council  consists  of  the  following,  or  their  principal  deputies: 

•  Assistant  Secretary  of  Defense  (Comptroller); 

•  Assistant  Secretary  of  Defense  (Command,  Control,  Communication,  and 
Intelligence); 

•  OSD  System  Sponsor  (e.g.,  ASD  (P&L)  or  ASD  (HA)  or  ASD  (FM&P)); 

•  Component  Assistant  Secretaries  (ADP/IRM  official); 

•  Director,  Program  Analysis  and  Evaluation; 

•  Director,  Operational  Test  and  Evaluation;  and 

•  Other  OSD  Principals  identified  by  the  MAISRC. 

The  OSD  System  Sponsor  Principal  represents  the  functional  area  supported  by  the 
AIS.  This  official  has  the' primary  lead  in  the  initial  stages  of  the  review  process,  acting  as 
Chairman  of  the  MAISRC  at  the  Milestone  0  milestone  review.  The  System  Sponsor  will 
maintain  close  coordination  with  the  Functional  Manager  of  the  Component  seeking  the 
major  acquisition.  The  System  Sponsor  must  be  convinced  that  there  is  indeed  a  valid 
requirement  and  certify  that  it  has  been  expressed  correctly.  Basically,  the  System  Spon¬ 
sor  should  ensure  that  the  system  being  developed  meets  the  requirements,  is  cost- 
effective,  and  technically  viable.  During  later  stages,  the  OSD  System  Sponsor  is  con¬ 
cerned  with  monitoring  performance  criteria,  the  test  environment,  system  acceptance, 
and  revalidation  of  the  need  throughout  the  LCM  development  cycle. 

Each  review  session  is  headed  by  a  Chairman  who  is  responsible  for  facilitating  the 
meeting,  resolving  questions,  and  ensuring  that  a  memorandum  is  signed  and  distributed 
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to  all  concerned  regarding  the  review’s  outcome.  Following  approval  of  the  Milestone  0 
review,  die  ASD  (Comptroller)  will  sit  as  Chairman  and  coordinate  all  future  reviews  and 
decisions  throughout  the  LCM  process. 

The  Principals  normally  meet  only  at  die  actual  review  session  in  die  AIS  life  cycle; 
however,  their  staff  will  prepare  them  in  advance  for  the  review.  Based  on  information 
gained  in  the  preparation,  the  Principals  may  choose  other  nonvoting  people  to  attend  the 
review,  such  as: 

•  Other  OSD  functional  users  of  the  AIS; 

•  Spokesperson  for  independent  assessment  activity; 

•  Other  Component  officials;  and 

•  Action  Officers  (AO). 

Each  Principal  may  designate  one  of  his/her  staff  as  a  Point  of  Contact  (POC)  who 
will  represent  die  Principal  in  informal  coordination  activities,  track  system  progress,  and 
coordinate  the  views  of  the  various  subelements  of  the  staff  for  that  functional  area. 
These  POCs  will  meet  with  the  PM  and  staff  to  prepare  for  the  MAISRC  review.  The  PM 
should  remember  that  these  individuals  are  responsible  for  preparing  the  Principals  for 
the  review.  The  more  knowledgeable  the  AOs  and  Principals,  the  smoother  the  review. 

At  Milestone  0,  one  AO  from  the  functional  areas  (System  Sponsor)  will  be  appointed 
as  a  “lead”  who  will  be  responsible  for  coordinating  all  preparations  for  the  pre-MAISRC 
meetings  as  well  as  the  formal  review.  In  this  capacity,  the  “lead”  will  work  closely  with 
the  MAISRC  Executive  Secretary  (a  member  of  the  Comptroller’s  staff)  in  the  planning  of 
the  review.  During  ail  remaining  phases,  the  lead  will  transition  to  the  Comptroller’s  staff, 
specifically  the  Director  of  Information  Resources  Management  Systems  (IRMS). 

A  more  detailed  discussion  of  the  AO’s  role  is  contained  in  Chapter  Three. 

2.2  LIFE  CYCLE  MANAGEMENT 

AIS  life  cycle  management  is  a  process  for  managing  an  automated  information  sys¬ 
tem  during  its  entire  life.  It  is  subdivided  into  five  broad  phases: 

•  Mission  Analysis/Project  Initiation; 

•  Concept  Development; 

•  Definition/Design; 

•  System  Development;  and 

•  Deployment/Operation. 

LCM  emphasizes  the  need  to  develop  and  manage  an  AIS  to  meet  the  user’s  require¬ 
ments,  stressing  competition  in  the  acquisition  process,  sound  financial  management,  and 
continuing  mission  evaluation.  It  strives  to  give  the  PM  as  much  authority  as  possible  and 
decentralizes  the  approving  process  as  low  as  feasible. 
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The  objectives  of  LCM  are: 

•  Early  “up-front”  planning; 

•  Management  accountability; 

•  Establishment  of  cost,  schedule  and  requirement  control  mechanisms; 

•  High  visibility  through  executive  oversight;  and 

•  Cost  effective  standardization. 

LCM  doctrine  recognizes  that  should  any  part  in  the  evolving  system  be  altered,  the 
remaining  parts  will  be  impacted  in  some  manner.  LCM  seeks  to  maintain  management, 
balance  and  discipline  over  these  changes.  Major  AIS  development  programs  often  un¬ 
dergo  requirement  changes  in  the  early  stages.  Unless  these  changes  are  brought  under 
control,  the  program  soon  becomes  unmanageable.  Further  changes  can  occur  due  to  the 
high  turnover  of  key  personnel  within  the  program  staff.  The  transfer  of  these  personnel 
causes  a  shifting  level  of  perceptions  of  where  the  program  is,  and  what  the  program 
intends  to  accomplish.  Without  disciplined  documentation,  management  techniques  would 
be  applied  against  a  moving  baseline.  Thus  the  prudent  manager  can  provide  this  consis¬ 
tent  framework  by  insisting  on  the  maintenance  of  a  thorough  and  accurate  documented 
account  of  the  system’s  acquisition  and  the  evolutionary  thought  process  which  built  the 
system.  This  is  accomplished  through  disciplined  documentation,  including  systems 
baselining. 

The  objective  of  LCM  documentation  is  to  provide  the  PM  and  staff  with  a  valuable 
set  of  tools  that  clearly  state  program  direction  and  planning.  The  documents  are  a  record 
of  both  technical  and  user  information  to  be  used  in  guiding  and  coordinating  the  current 
work  effort  and  planning  the  future  development.  They  should  be  kept  current  by  modifi¬ 
cations  made  to  each  appropriate  document  any  time  an  approved  change  has  been  made. 
Finally,  they  provide  a  degree  of  uniformity  throughout  DoD  that  facilitates  outside  in¬ 
spection  of  the  ongoing  program. 

While  the  review  council  may  want  to  review  various  backup  documents  during  the 
program’s  evolution,  the  PM  must  always  maintain  the  following  documents  and  submit 
them  at  each  review: 

•  Mission  Essential  Need  Statement  (MENS); 

•  System  Decision  Paper  (SDP);  and 

•  Program  Manager’s  Charter 

DoD-STD-7935,  dated  15  February  1983,  outlines  further  documents  to  be  produced 
during  the  life  cycle  of  the  system.  Some  of  these  may  be  requested  by  the  OSD  AO  for 
review  in  preparing  for  a  MA1SRC  review  (per  DoDI  7920.2).  They  are: 

•  Functional  Description  (FD); 

•  Data  Requirements  Documents  (RD); 


•  System/Subsystem  Specification  (SS); 

•  Program  Specification  (PS); 

•  Data  Base  Specification  (DS); 

•  Users  Manual  (UM); 

•  Computer  Operation  Manual  (OM); 

•  Program  Maintenance  Manual  (MM); 

•  Test  Plan  (TP); 

•  Test  Analysis  Report  (TR); 

•  Implementation  Procedures  (IP);  and 

•  Others  as  prescribed. 

Early  in  the  program,  the  PM  must  decide  on  those  document  types  required  as  well 
as  information  about: 

•  The  level  of  detail  of  each  document  type; 

•  When  each  is  to  be  produced; 

•  Quality  assurance; 

•  Provisions  for  document  review  and  updating;  and 

•  Who  will  prepare  each  document. 

Table  2—1,  LCM  References,  identifies  major  documents  pertaining  to  acquisitions 
and  the  LCM  process.  The  PM  should  obtain  and  be  familiar  with  these  documents  since 
they  describe  the  PM’s  environment  and  the  rules  that  govern  AIS  development.  Further, 
OSD  memoranda  concerning  these  topics  are  included  as  appendixes  to  this  Guideline. 

2.3  MILESTONE  DECISION  POINTS 

Enclosure  2  to  DoDD  7920.1  describes  the  four  major  milestone  decisions  during  the 
system’s  life  cycle.  Before  advancing  to  the  next  developmental  phase,  the  PM  must 
obtain  DoD  approval,  or  Service  approval  if  the  approval  process  has  been  delegated  to 
the  Component.  The  decision  points  will  be  briefly  summarized  in  the  succeeding 
paragraphs,  emphasizing  the  major  areas  that  the  PM  must  address. 
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The  twofold  purposes  of  this  phase  are  to  identify  and  validate  needs  expressed  as 
functional  requirements  and  to  recommend  the  exploration  of  alternate  functional  con¬ 
cepts.  It  answers  the  question  “What  do  we  want?”. 

Specific  concerns  to  be  addressed  at  the  Milestone  0  decision  point  involve: 

•  Quantifying  the  identified  mission  deficiencies  and  goals  for  improvement; 

•  Characterizing  the  current  and  projected  environment; 


TABLE  2-1  LCM  REFERENCES 


DoOO  7920.1 

LCM  of  AIS 

DoOi  7920.0 

Major  AIS 
Approach  Process 

Service 

Regulations 

Defines  Major  AIS 

System  Decision 

Paper  (SDP)  Process 

AFR  700  Series 

Management  Accountability 

OSD  Review  and 

SECNAVINST  5231.1B 

Roles  and  Responsibilities 

Approval  Process 

SECNAVWMST  5236.1 

Life  Cycle  Phases  and 

Approval 

AR  25-1 

Policies 

Relationships 

AR  25-5 

Mission  Element  Need 

AIS  Milestones  and 

Statement  (MENS) 

Tasks 

Estimating  overall  costs; 

Determining  affordability  constraints; 

Describing  the  system’s  needs  with  clarity  and  focus; 

Determining  what  needs  can  be  satisfied  within  current  capabilities; 

Establishing  need  priorities;  and 

Determining  the  timing  and  urgency  of  the  needs. 


2.3.2 


This  phase  involves  developing  and  evaluating  alternate  means  to  satisfy  a  mission 
need  and  to  recommend  one  or  more  concepts  for  further  exploration.  It  answers  the 
questions  “What  are  our  plans  to  satisfy  the  need?”,  “What  are  the  alternatives 
considered?”,  and  “What  do  we  recommend?”. 


Specific  objectives  to  be  addressed  are: 

•  Defining  alternate  functional  concepts; 

•  Weighing  the  risks  of  each  workable  concept; 

•  Selecting  a  concept  based  upon  an  adequate  analysis  that  it  will  work; 

•  Developing  a  practical  approach,  to  include  demonstrations  if  required; 

•  Defining  alternate  architecture  concepts; 

•  Developing  an  acquisition  strategy; 

•  Conducting  a  cost-benefit  analysis;  and 

•  Determining  an  initial  cost  estimate. 


2.3.3  Deflnitlna  aad  Design  (Milestone  Hi 


The  purposes  of  this  phase  are  to  define  fully  the  system’s  functional  requirements 
and  to  design  a  working  AIS.  It  answers  the  question  “Is  the  design  satisfactory?”. 

At  this  decision  point  the  PM  must: 

•  Document  and  validate  functional  requirements; 

•  Weigh  the  risks  of  each  alternate  design; 

•  Select  the  best  design; 

•  Validate  ADP/T  adequacy; 

•  Complete  the  economic  analysis; 

•  Obtain  sign-offs  by  functional  proponent  and  technical  managers; 

•  Develop  a  firm  baseline  for  requirements,  costs,  and  schedule;  and 

•  Provide  for  full  funding  of  the  program. 


The  purpose  of  this  phase  is  to  develop,  integrate,  test,  and  evaluate  the  ADP  system 
and  the  total  AIS.  It  answers  the  question  “Is  the  system  ready  for  deployment?”. 

At  this  key  decision  point  the  PM  must  address  the: 

•  Completion  of  the  development  of  the  system; 

•  Adequate  testing  and  evaluating  of  the  system; 

•  Implementation  planning; 

•  Current  risk  assessment  and  future  risk  management  actions; 

•  Current  requirements,  costs,  and  schedule  baselines;  and 

•  Full  funding  of  the  program. 
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CHAPTER  THREE 
DYNAMICS  OF  THE  MAISRC 


3.0  THE  REVIEWS 

The  Major  Automated  Information  System  Review  Council  (MAISRC)  reviews  are 
normally  preceded  by  a  Component  review.  As  the  two  types  of  reviews  complement  each 
other,  preparation  activities  for  the  MAISRC  review  should  pose  little  additional  burden 
on  the  Program  Manager  (PM).  The  goal  of  the  process  is  to  be  constructive.  Not  all  of 
the  following  activities  are  always  required.  What  is  essential  is  that  early  planning  and 
communication  occurs  as  a  basis  for  smooth  MAISRC  processing  of  the  program. 

The  PM  should  be  prepared  to  present  the  program  plans  and  analyses  and  decisions 
reached  in  managing  die  program.  This  should  provide  a  basis  for  meeting  the  MAISRC 
requirements,  providing  they  have  been  thoroughly  accomplished  and  cover  appropriate 
areas  for  analysis.  The  PM  should  see  the  review  as  an  opportunity  to  validate  the 
accuracy  of  program  planning.  The  review  should  be  approached  by  developing  a  logical 
presentation  that  stresses  the  analytical  approach  to  the  system’s  development.  Backup 
data  that  might  prove  beneficial  to  the  council’s  understanding  of  the  program  should  be 
made  available  to  the  MAISRC  staff  well  in  advance  of  the  review. 

The  following  sections  discuss  briefly  the  DoD  preparation,  the  actual  conduct  of  the 
review,  and  the  post  conduct  phase. 

3.1  PREPARATION  PHASE 

The  following  serves  as  a  general  model  of  the  sequence  of  events  leading  to  a 
MAISRC.  However,  the  sequence  is  tailored  to  the  specific  system.  While  having  several 
events,  the  OSD  preparatory  phase  is  structured  to  minimize  impact  on  the  program 
office  and  at  the  same  time  allow  for  routine  advance  planning,  which  should  significantly 
smooth  the  process  leading  to  the  MAISRC  review  and  any  program  office  workload. 
These  meetings  take  place  at  the  Action  Officer  (AO)  level  and  the  program  office  should 
be  able  to  answer  most  of  the  expected  questions  from  existing  normal  program 
documentation.  Milestone  Planning  Meetings  set  the  milestones  or  sequences  of  events 
leading  to  the  MAISRC  and  are  normally  scheduled  4  to  6  months  in  advance  to  allow  for 
an  orderly  progression  to  the  MAISRC.  If  this  is  the  first  time  a  program  has  come  before 
the  MAISRC,  there  probably  will  be  more  meetings  scheduled  so  that  the  PM  and  staff 
can  orient  the  Office  of  the  Secretary  of  Defense  (OSD)  AOs  on  the  entire  program. 

About  1  month  after  the  Milestone  Planning  Meeting,  the  PM  should  submit  a  System 
Decision  Paper  (SDP)  outline  to  the  OSD  AOs,  who  will  review  it  and  provide  comments 
to  the  PM  for  resolution  in  the  SDP. 

About  3  months  before  the  scheduled  MAISRC,  the  PM,  the  PM’s  staff,  and  the  OSD 
will  hold  an  informal  status  review  to  determine  the  progress  of  the  preparations  and 
readiness  of  the  program  to  meet  the  MAISRC. 


Approximately  10  weeks  before  the  scheduled  review,  the  PM  should  submit  a  draft 
SDP  to  the  OSD  AOs,  who  will  again  comment  and  return  it  2  weeks  later.  The  PM  will 
have  approximately  2  weeks  to  finalize  the  SDP  and  submit  the  final  version  6  weeks 
before  the  scheduled  decision  meeting. 

The  OSD  AOs  will  analyze  the  SDP  and  other  program  data  and  prepare  issue  papers 
for  their  own  Principals.  These  issues  will  be  shared  with  the  PM  to  help  resolve  them 
prior  to  the  MAISRC.  Three  weeks  before  the  meeting,  the  AOs  will  hold  a  prebrief  to 
review  the  PM’s  decision  brief  and  decide  if  all  the  preparations  are  complete  and  all 
issues  have  been  identified  and  resolved,  if  possible. 

During  this  preparation  phase,  the  OSD  AO  will  review  data  and  documentation  from 
the  PM  that  will  be  used  to  support  a  MAISRC  decision.  The  AO  will  prepare  a  decision 
package  (Blue  Book)  for  each  Principal,  releasing  the  package  approximately  10  days 
prior  to  the  review.  Three  days  before  the  review,  the  Principals  will  receive  a  prebrief 
from  die  Lead  AO  using  the  information  contained  in  the  Blue  Book.  Normally  the 
contents  of  the  Blue  Book  include: 

•  Purpose  and  type  of  review; 

•  Agenda; 

•  Attendee  List; 

•  Background,  containing  a  management  summary  of  the  program  and  current 
issues; 

•  Previous  System  Decision  Memorandum  (SDM); 

•  Program  Milestones; 

•  Program  Status; 

•  Program  Funding; 

•  Congressional,  Government  Accounting  Office  (GAO),  DoDIG  concerns;  and 

•  Briefing  Charts. 

3.1.1  Hie  System  Decision  Paper 

This  program  summary  document  should  be  presented  to  the  DoD  staff  in  final  draft 
form  approximately  6  weeks  before  the  MAISRC  meeting.  This  document  will  support 
both  the  DoD  and  Component  reviews,  coordination,  and  decisions.  It  should  be  kept 
current  at  all  times  and  be  resubmitted  to  OSD  before  each  subsequent  MAISRC  review. 
The  SDP  is  a  management  summary  of  the  program  as  well  as  a  decision  paper.  It 
represents  a  Component  staff  coordination  position  and  becomes  a  contract  document 
between  OSD  and  the  Component.  The  document  will  be  tailored  to  the  particular  life 
cycle  phase  of  the  AlS-related  issues  and  the  specific  decision  needed  to  advance  to  the 
next  stage  of  development. 
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Enclosure  1  to  DoDl  7920.2  contains  information  on  the  SDP.  As  a  minimum,  it 
specifically  provides  for  the  following  contents: 

•  Mission  Element  Need  Statement  (MENS); 

•  Program  Management  Plan  (PMP); 

•  Acquisition  Strategy; 

•  Logistics  and  Training  Support; 

•  Resources  (including  a  cost/benefit  analysis);  and 

•  Test  and  Evaluation  Plan. 

As  the  program  evolves,  the  PM  will  put  in  place  internal  documentation  that 
demonstrates  the  level  of  thinking,  analysis,  and  planning  put  into  the  program.  The 
following  contains  topics  that  should  be  in  a  well  managed  program  and  for  which  the  PM 
may  wish  to  make  cross-reference  in  the  SDP.  These  documents  identify  and  illustrate  the 
discussion  of  alternatives  and  rationale  for  their  selection  and  also  illustrate  the  level  of 
planning  for  future  phases  of  the  program. 

•  PM  charter, 

•  Alternate  concepts  and  selection; 

•  Demonstrations; 

•  Architecture  strategy; 

•  Functional  requirements  in  priority; 

•  Support  plans  for: 

—  Transition 
—  Security 
—  Contingency 
—  Maintenance 
—  Competition 
—  Quality  control 
—  Validation/verification 
—  Implementation 
—  Site  preparation 
—  Procurement 
—  Post  deployment 
—  Software  conversion 
—  Configuration  management 
—  Communications 

•  Most  recent  budget  data; 

•  Risk  assessment  and  management; 

•  Schedule  management  and  milestones; 
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Status  of  Life  Cycle  Management  (LCM)  documents; 
Interface  requirements; 

Integration  management; 

Economic  Analysis; 

Standards/interoperabilities; 

Goals/objectives; 

Alternate  designs  and  selection; 

Model/simulation  considerations;  and 


•  Pilot  processing. 

The  SDP  (which  includes  the  MENS  and  PM  charter)  thus  becomes  the  only  specific 
new  document  required  of  the  PM  by  the  MAISRC.  Because  the  PM  will  already  have 
analyzed  and  documented  these  topical  areas  long  before  the  milestone  review,  the  work 
previously  done  can  be  summarized  in  the  SDP  and,  if  needed,  can  be  included  as 
appendixes. 


3.1.2  Identifying  and  Resolving  Issues 

The  PM  should  focus  planning  efforts  on  early  identification  and  resolution  of 
program  issues.  The  primary  function  at  the  MAISRC  review  is  to  resolve  issues  and 
move  the  program  forward,  if  possible.  If  the  PM  has  resolved  OSD  issues  beforehand, 
the  review  should  be  straightforward. 


At  the  Milestone  Planning  Meeting,  the  OSD  AOs  and  the  PM  should  attempt  to 
identify  the  issues,  questions,  and  potential  problems  to  be  worked  over  the  next  few 
months.  The  OSD  AOs  and  PM  should  work  in  harmony  to  ensure  that  issues  have  been 
identified,  available  options  considered  and  the  best  option  selected.  If  no  decision  has 
been  reached  and  major  risk  is  involved,  then  the  PM  must  present  all  background  data 
on  the  subject  to  the  MAISRC  for  the  Principals’  decision.  The  PM  should  especially 
attend  to  concerns  such  as  validity  of  data  and  sufficiency  of  analysis  that  might  require 
lengthy  time  to  resolve. 

3.1.3  Mission  Element  Need  Statement 

The  MENS  provides  the  current  statement  of  need  and  is  revalidated  or  revised  at 
each  milestone.  The  PM  will  resubmit  it  to  DoD  along  with  other  required  MAISRC 
documents.  It  is  a  management  document  and  its  content  is  set  forth  in  Enclosure  3  to 
DoD  Directive  7920.1.  The  MENS  also  describes  constraints  that  may  influence  the  choice 
of  solutions  to  meet  the  identified  need.  Further,  the  MENS  contains  cost  and  investment 
parameters  and  states  the  time  required  to  satisfy  the  need. 

$  Aspects  that  should  be  addressed  include  (1)  priority  of  the  need  in  relation  to  other 
^  Service  needs,  (2)  limits  on  investment,  (3)  limits  on  recurring  and  operating  costs, 
(4)  standards  and  interoperability  requirements,  (5)  critical  interdependencies  or 
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interfaces,  (6)  logistic  and  manpower  considerations,  and  (7)  security  and  wartime 
survivability. 

Although  the  MENS  can  be  submitted  at  anytime,  it  should  be  integrated  with  the 
Program  Objectives  Memorandum  (POM)  if  practicable.  The  MENS  is  validated  as  part  of 
the  Component  and  MAISRC  staffing  process.  Once  the  DoD  approves  the  MENS,  the 
OSD  will  write  a  System  Decision  Memorandum  (SDM)  to  announce  its  decision.  The 
SDM  provides  milestone  approval  for  a  major  AIS  and  authorizes  the  DoD  Component  to 
start  the  next  acquisition  phase.  After  each  milestone  approval,  the  PM  must  update  the 
MENS  to  keep  it  current. 

3.1.4  Reaffirm- Need 

Both  operational  and  developing  systems  undergo  changes.  Any  large  system  requires 
periodic  evaluations  during  its  life  cycle  to  determine  its  relevancy,  effectiveness,  and 
efficiency.  Long-range  plans  can  change  due  to  modifications  in  function  and  technology; 
sometimes  these  changes  can  be  both  dramatic  and  sudden.  Consequently,  the  PM  must 
determine  at  each  milestone  whether  the  program’s  needs  are  still  valid  and  whether  the 
cost-effectiveness  criteria  remain  the  same. 

If  either  or  both  are  no  longer  valid,  the  PM  must  notify  the  Component  and  be 
prepared  to  explore  new  developments.  In  most  cases,  however,  the  needs  and  cost 
effectiveness  will  remain  stable.  The  PM  should  positively  state  this  reaffirmation  in  the 
updated  MENS. 

3.2  CONDUCT  OF  THE  MAISRC 

There  are  two  levels  of  review  that  can  be  conducted  to  suit  varying  circumstances: 
the  milestone  review  and  the  in-process  review.  Each  will  be  discussed  below.  The  make 
up  of  the  review  board  will  be  tailored  appropriately.  The  PM  will  be  expected  to  address 
those  issues  outlined  in  Section  2.3  or  others  brought  up  during  the  OSD  staff  review 
process. 

3.2.1  Milestone  Review 

The  milestone  review  is  conducted  at  one  of  the  four  milestone  decision  points.  The 
purpose  of  a  milestone  review  is  to  seek  approval  to  proceed  on  to  the  next  phase  of  the 
life  cycle  based  upon  results  of  activities  from  the  past  and  plans  for  the  future. 

This  review  will  be  conducted  by  the  MAISRC  Principals  (see  Section  2.1.4).  They 
will  have  received  an  earlier  briefing  on  the  purpose  of  the  review,  decisions  that  must  be 
made,  and  issues  that  must  be  resolved.  Any  unresolved  major  issues  that  constitute 
major  risks  must  be  presented  to  the  MAISRC.  Based  on  the  MAISRC  review  and  SDP 
previously  submined,  the  MAISRC  will  issue  an  SDM  approving  progression  to  the  next 
phase  or  directing  future  action. 


3.2.2  In-process  Reviews 

In-process  reviews  generally  cover  program  progress  between  major  milestones  or  for 
any  other  needed  review  that  does  not  fit  the  traditional  milestone  review.  For  example,  if 
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a  particular  phase  extends  over  a  3-year  period,  the  MAISRC  may  want  to  be  updated 
annually  or  semi-annually.  However,  the  Chairman  can  order  special  reviews  to  evaluate 
or  obtain  data  on  a  specific  topic  such  as  acquisition  strategy,  schedule  slippages,  or 
resource  difficulties.  The  OSD  principals  may  delegate  certain  in-process  reviews. 

3.3  POST  MAISRC  PHASE 

Shortly  after  the  MAISRC  finishes  its  review,  it  will  notify  the  Component  of  its 
decision  and  direction  through  an  SDM,  normally  within  3  weeks. 

3.3.1  System  Decision  Memorandum 

The  SDM  documents  the  results  of  the  MAISRC,  provides  program  direction,  and 
includes  approval  of  program  goals,  cost,  schedule,  performance,  supportability,  test  and 
evaluation,  and  standardization. 

The  Lead  AO  normally  drafts  and  staffs  the  SDM,  the  MAISRC  Principals  and 
Chairman  sign  it,  and  the  MAISRC  sends  it  to  the  PM  or  the  DoD  Component.  The  SDM 
will  summarize  all  key  issues  brought  before  the  MAISRC,  document  decisions  made,  and 
provide  guidance  to  be  applied  before  the  next  MAISRC  meeting.  If  the  MAISRC  believes 
that  the  program’s  oversight  authority  should  be  delegated  to  the  DoD  Component,  the 
SDM  will  so  state. 

3.4  ADP  ACQUISITION  IMPROVEMENTS  PROGRAM 

OSD  constantly  strives  to  improve  the  management  process  by  upgrading  the  quality 
of  program  management  and  program  products.  The  most  recent  effort  that  focuses  on 
these  improvements  is  discussed  in  Appendix  H. 


CHAPTER  FOUR 
QUESTIONS  TO  BE  ANSWERED 


4.0  BACKGROUND 

During  the  preparation  stages  for  the  Major  Automated  Information  System  Review 
Council  (MAISRC)  review,  Action  Officers  (AO),  and  others  assigned  to  assist  the 
Principals  of  the  Council,  become  familiar  with  significant  amounts  of  background  data 
about  the  major  Automated  Information  System  (AIS)  program.  Sample  questions,  which 
may  be  asked  by  both  AO  and  Principals,  are  reflected  in  this  Chapter. 

These  questions  can  be  of  use  to  all  Program  Managers  (PM),  regardless  of  whether 
they  are  undergoing  a  MAISRC.  They  can  be  used  as  a  reminder  or  checklist  to  the  PM  to 
ensure  that  all  issues  have  been  considered  and  addressed.  In  the  early  stages  the  level  of 
detail  for  each  issue  may  not  be  great.  As  the  concepts  of  the  AIS  come  into  focus  and 
ctystallize,  the  questions  and  answers  can  be  expected  to  be  more  specific  and  the 
Principals  will  require  the  PM  to  provide  explicit  responses. 

Some  questions  under  the  information  categories  tend  to  be  repetitive  in  a  useful  way. 
Since  there  is  a  need  for  the  PM  to  review  each  issue  from  its  inception  through  its 
current  state  and  beyond,  the  questions  concerned  should  serve  the  PM  throughout  the 
development  effort. 

Table  4-1  depicts  a  matrix  of  information  categories  that  should  be  addressed  by  the 
PM  at  different  milestone  decision  points.  Some  of  these  must  be  addressed  at  each 
review:  mission,  needs,  management,  interface,  costs,  and  resources.  Two  other 
information  categories  qqi  specifically  identified  are  included  in  several  of  the 
information  categories;  these  are  risk  and  schedule.  Failure  to  list  these  individually  does 
not  lessen  their  importance;  rather,  it  was  determined  that  risk  and  schedule  can  best  be 
addressed  within  the  other  categories. 

The  PM  should  also  note  that  there  is  some  overlap  between  the  information 
categories.  For  example,  questions  concerning  “costs”  are  also  included  in  the 
“management”  category. 

The  PM  may  note  that  some  very  important  functions/products  have  been  omitted. 
For  example,  specific  Configuration  Management  (CM)  questions  do  not  appear  in  this 
Guideline.  CM  is  omitted  because  the  MAISRC  considers  CM  to  be  more  of  a  technical 
item  than  an  issue  that  might  affect  the  MAISRC.  The  MAISRC  seeks  assurance  that 
there  is  an  AIS  CM  plan  in  effect;  it  is  less  concerned  with  the  mechanics  of  how  it  is 
being  accomplished.  The  MAISRC  wants  to  be  assured  that  there  is  a  consistent 
framework  for  the  development  effort  and  that  disciplined  and  quality  thinking  has  been 
given  to  the  program. 


4-1 


4.1  MISSION 


The  following  mission-related  questions  apply  to  milestones  0,  I,  II,  and  III. 

1.  What  are  the  risks  that  can  impair  the  organization  from  properly  accomplishing 
the  functional  mission? 

2.  What  is  the  peacetime  mission  that  the  ADP  system  will  accomplish?  What  is  the 
wartime  mission?  Describe  the  steps  that  must  be  taken  to  bring  the  organization 
and  the  system  up  to  a  wartime  mission  level. 

3.  Are  additional  interfaces  required  and  identified  for  wartime  conditions?  Describe 
how  these  are  to  be  satisfied. 

4.  Have  any  changes  been  made  to  the  mission  or  are  any  changes  contemplated  for 
the  near  future? 

5.  What  is  the  life  expectancy  of  the  proposed  system?  Describe  the  expected 
environment  during  the  critical  stages  of  the  development  effort. 

4.2  NEEDS 

These  needs  questions  must  be  answered  at  milestones  0,  I,  II,  and  III. 

1.  What  needs  are  currently  being  satisfied?  What  needs  remain  to  be  satisfied? 

2.  What  deficiencies  can  be  quantified  in  terms  of  time  and  money?  Are  there  other 
means  of  quantifying  the  deficiencies? 

3.  What  are  the  causes  of  the  deficiencies  (mission  change,  environment  change, 
inefficiencies,  technology,  etc.)? 

4.  Do  expressed  needs  arise  from  failure  of  the  current  system  or  more  efficient 
mission  fulfillment  due  to  improved  technology?  Explain. 

5.  What  backup  facilities  exist  to  ensure  the  current  mission  can  be  accomplished 
while  the  new  system  is  being  developed? 

6.  What  means  were  taken  to  ensure  that  the  stated  prioritized  needs  do  not  include 
“nice-to-have”  needs? 

7.  Are  needs  expressed  in  terms  of  functional  requirements  rather  than  in  hardware- 
oriented  terms? 

8.  Does  the  MENS  address  interim  upgrades,  urgencies,  impacts? 

9.  What  needs  have  changed  since  the  last  life  cycle  phase? 

10.  Has  the  MENS  been  upgraded?  Describe  all  changes  to  the  MENS  and  when  they 
occurred.  When  was  the  last  mission  need  affirmation? 

11.  Is  the  statement  of  need  clear  and  focused? 

12.  What  functional  or  mission  benefits  accrue  from  implementation  of  the  new 
system? 


4.3  FUNCTIONAL  REQUIREMENTS 


These  questions  must  be  answered  at  milestone  I. 

1.  What  are  the  functional  goals/objectives  of  the  new  system? 

2.  Have  all  functional  requirements  been  defined,  quantified,  and  documented? 
Describe  the  procedures  to  ensure  that  these  requirements  are  continually 
assessed  and  that  the  baseline  is  maintained. 

3.  What  was  the  basis  for  the  prioritization  of  the  functional  requirements? 

4.  Has  a  functional  manager  been  appointed?  What  duties  does  this  person  have? 

5.  Describe  the  user's  role  in  developing  the  functional  requirements.  Will  the  user 
have  any  role  in  determining  functional  satisfaction? 

6.  How  will  functional  requirement  satisfaction  be  determined?  Describe  the 
validation  process. 

7.  What  is  the  process  for  approving/disapproving  functional  requirement  changes, 
additions,  and  deletions?  Outline  the  functional  manager’s  role  in  this  process. 
Outline  the  PM’s  role  in  this  process. 

8.  Who  validated  the  initial  functional  requirements?  Describe  the  actions  taken  to 
evaluate  the  alternate  concepts/designs  satisfying  functional  requirements. 

9.  To  what  extent  has  coordination  been  made  with  other  functional  managers 
regarding  functional  adequacy? 

10.  What  steps  have  been  taken  to  ensure  the  system  can  satisfy  “surge” 
requirements?  Have  “surge”  requirements  been  identified  and  quantified? 

4.4  MANAGEMENT 

These  questions  must  be  answered  at  milestones  0,  I,  II,  and  III. 

1.  What  control  mechanisms  have  been  established  to  ensure  that  the  AIS  is 
developed,  evaluated,  and  operated  in  an  effective  manner  at  the  lowest  total 
overall  cost? 

2.  What  provisions  have  been  made  to  ensure  that  progress  can  be  measured 
effectively  and  supporting  data  can  be  produced  in  a  timely  manner? 

3.  What  development  tools  were  considered  and  will  be  used  to  facilitate  technical 
solutions  to  problems? 

4.  How  will  the  feasibility  of  the  new  system  design  be  determined?  What  will  occur 
if  the  new  system  design  is  not  feasible? 

5.  Describe  the  internal  review  procedures.  Who  will  review  for  key  criteria 
(portability,  reliability,  maintainability)? 


6.  Does  the  management  plan  identify  organizational  relationships  and  responsibili¬ 
ties  for  management  and  support  during  each  phase? 

7.  Has  independent  verification  and  validation  been  considered?  What  was  the  basis 
for  the  decision? 

8.  What  audits  are  scheduled  or  planned? 

9.  Have  personnel  been  identified  to  oversee  specific  areas  in  acquisitions?  Software 
development?  Test  and  evaluation? 

10.  What  tracking  measures  are  used  to  ensure  that  milestone  dates  are  met? 

11.  What  procedures  are  used  to  monitor  costs?  How  will  costs  be  tracked? 

12.  What  are  the  areas  of  greatest  risk  (technical,  cost,  schedule)?  How  will  they  be 
managed?  What  is  the  plan  to  reduce  risk?  What  are  the  consequences  if  goals  are 
not  attained? 

13.  Have  funding  requirements  been  identified?  Is  the  program  fully  funded?  If  not, 
why  not? 

14.  How  are  support  requirements  established  during  each  phase?  How  will  they  be 
monitored? 

15.  What  management  procedures  will  be  used  to  control  costs  in  the  software 
development? 

16.  What  are  the  expected  tradeoffs  among  cost,  schedule,  and  performance  goals? 

17.  How  is  the  program  organized?  Describe  it. 

18.  Have  provisions  for  processing  “exercise  traffic”  been  incorporated  into  the 
system  requirements  for  “essential”  systems? 

19.  How  will  the  program  take  advantage  of  changes  in  technology  that  occur  between 
now  and  deployment? 

20.  What  is  the  Program  Manager’s  authority  and  responsibility? 

4.5  COSTS 

These  questions  must  be  answered  at  milestones  0,  I,  II,  and  III. 

1.  What  are  the  overall  program  cost  goals?  Identify  and  estimate  the  costs.  How  will 
cost  performance  be  measured? 

2.  What  are  the  acquisition  cost  goals?  What  is  the  rationale  for  supporting  them? 
How  will  performance  be  measured? 

3.  Was  a  cost/benefit  study  performed  on  each  workable  alternative?  How  was  this 
developed?  Describe  the  review  and  approval  process. 


4.  Was  a  detailed  economic  analysis  performed  on  each  alternate  design?  Were 
revisions  made  to  the  total  program  costs  after  functional  and  technical 
adequacies  were  confirmed? 

5.  Was  an  attempt  made  to  analyze  a  return  of  investment?  What  were  the  results? 

6.  How  will  life  cycle  costs  be  developed  and  used  in  determining  a  “best  buy”? 
Have  costs  changed  since  the  last  life  cycle  phase? 

7.  How  is  cost  visibility  being  maintained?  How  are  costs  tracked? 

8.  What  are  the  life  cycle  costs  and  benefits? 

4.6  ARCHITECTURE 

These  questions  must  be  answered  at  milestone  I. 

1.  How  do  the  building  blocks  (e.g.,  hardware,  systems  software,  communications, 
data  bases)  interact  in  the  chosen  architecture? 

2.  How  does  the  system  architecture  fit  in  with  the  Service  architecture? 

3.  What  were  the  alternative  architectures?  Why  were  they  rejected?  What  were  the 
dominant  criteria  leading  to  the  selection  of  the  designated  architecture? 

4.  What  were  the  costs  and  benefits  associated  with  each  alternative? 

5.  What  are  the  risks  associated  with  the  selected  architecture? 

6.  How  will  the  architecture  satisfy  the  Service  needs? 

7.  In  what  environment  must  the  architecture  function? 

4.7  ACQUISITION  STRATEGY 

These  questions  must  be  answered  at  milestones  1,  II,  and  III. 

1.  What  are  the  goals  and  objectives  of  the  overall  acquisition  strategy? 

2.  Must  all  functional  requirements  be  satisfied  at  once?  Is  phasing  conceivable? 
How  can  it  be  accomplished? 

3.  Has  there  been  an  effort  to  obtain  or  use  other  Government  hardware/software/ 
telecommunication  to  satisfy  the  need  in  total,  or  in  part? 

4.  Describe  efforts  to  secure  off-the-shelf  software  to  satisfy  requirements.  Are 
there  legal  restrictions  for  modifying  off-the-shelf  or  vendor  software? 

5.  What  were  key  considerations  in  your  decision  for  or  against  equipment 
augmentation?  equipment  updates? 


6.  What  is  the  program  planning  schedule  for  making  acquisition  decisions? 

7.  What  are  the  risks  associated  with  schedule?  costs? 

8.  Has  a  plan  been  prepared  for  each  item  or  service  to  be  procured? 

9.  What  is  the  extent  of  contractor  involvement?  How  is  this  to  be  managed?  Does 
the  organization  have  the  capability  to  manage  contract  support? 

10.  What  is  the  Contracting  Officer’s  involvement  in  the  acquisition  effort? 

11.  How  will  the  acquisition  strategy  enhance  competition? 

12.  Have  evaluation  criteria  and  standards  to  be  used  by  the  Source  Selection 
Evaluation  Board  (SSEB)  been  fully  developed  prior  to  release  of  the  RFP?  Have 
operational  test  plans  been  developed  and  approved  by  the  Service  or  the  Director, 
Operations,  Test  &  Evaluation? 

13.  What  is  the  program  development  strategy  regarding  such  issues  as  prototyping, 
phased  development,  phasing  of  acquisitions? 

4.8  COMPETITION 

These  questions  must  be  answered  at  milestones  I  and  II. 

1.  Outline  the  program’s  competition  strategy.  How  is  true  competition  assured  for 
each  item  to  be  procured?  How  will  competition  be  sought,  promoted,  and 
sustained? 

2.  Has  a  competition  individual  been  appointed  to  coordinate  with  the  Contracting 
Officer? 

3.  How  can  the  program  be  made  more  competitive? 

4.  What  are  the  program’s  planned  actions  if  only  one  response  is  deemed  workable? 

5.  What  are  the  contracting  considerations  for  each  acquisition  as  to  options? 
warranties?  deviations?  multiyear  procurement? 

6.  What  procedures  and  cautions  have  been  taken  to  preclude  drafting  the 
specifications  in  a  restrictive  manner? 

7.  What  are  the  source  selection  procedures  for  each  acquisition?  Include  timing  for 
submission  and  evaluation  of  proposals. 

8.  What  is  the  relative  importance  ascribed  to  a  given  vendor’s  ability  to  meet  the 
mission  needs  in  terms  of  schedule?  cost?  prior  performance? 

9.  How  much  detail  will  the  vendor  be  provided  in  the  criteria  to  be  used  in  the 
evaluation  and  selection  process? 

10.  Were  vendor  briefings/orientations  considered  and  given? 

11.  What  is  the  composition  of  the  evaluation  team  and  what  considerations  were  used 
in  the  selection  of  the  team  members? 
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4.9  RESOURCES 

These  questions  must  be  answered  at  milestones  0,  I,  II,  and  III. 

1.  What  methodologies  were  used  to  estimate  resources? 

2.  What  are  the  categories  of  personnel  needed  for  the  new  system?  Are  changes 
needed  in  the  Service  training  programs? 

4.10  TRAINING 

These  questions  must  be  answered  at  milestones  II  and  III. 

1.  Describe  your  plan  to  train  on-board  personnel  on  using  the  new  hardware, 
software.  Are  new  skills  involved?  Outline  the  schedule,  method,  cost,  sites,  and 
equipment. 

2.  What  are  your  plans  to  train  the  follow-on  personnel? 

3.  What  manuals/documents  are  planned  for  production?  What  is  their  publication 
schedule?  Who  will  write  them  and  who  will  maintain  them? 

4.  What  plans  are  there  to  train  management? 

5.  How  much  in-house  training  is  necessary?  Who  will  conduct  it? 

6.  How  were  training  requirements  determined? 

4.11  INTERFACE  AND  ADP/T 

These  questions  must  be  answered  at  milestones  0,  I,  II,  and  III. 

1.  Identify  and  document  all  interfaces  and  standards  requirements  with  other 
systems.  How  are  these  being  accommodated?  Are  any  changes  expected? 

2.  Describe  the  efforts  to  coordinate  communications  needs  with  appropriate  DoD 
agencies. 

3.  What  are  the  requirements  as  they  pertain  to  standards?  interoperability? 

4.  What  is  the  strategy  to  identify  and  evaluate  future  ADP/T  concepts  and 
capabilities? 

5.  What  is  the  criteria  used  to  select  among  different  ADP/T  concepts? 

6.  What  are  the  key  interface  issues  to  be  addressed? 

7.  How  have  ADP/T  considerations  been  integrated? 

8.  What  ADP/T  concepts  were  considered? 


9.  Has  interoperability  been  planned  for?  What  are  the  plans  to  migrate  to  Defense 
Data  Network  (DDN)? 

10.  What  internal  office  serves  as  an  ADP/T  focus?  What  are  its  tasks? 

11.  What  plans  have  been  made  to  interface  with  industry? 

4.12  SECURITY 

These  questions  must  be  answered  at  milestones  0,  I,  and  II. 

1.  What  provisions  have  been  made  for  backing  up  the  system  in  case  of  natural  or 
wartime  disasters? 

2.  Describe  the  security  requirements  and  outline  the  concept  to  ensure  their 
protection  (computer  security,  data  security  and  privacy). 

4.13  DESIGN 

These  questions  must  be  answered  at  milestones  I  and  II. 

1 .  How  does  the  new  design  ensure  portability? 

2.  How  does  the  AIS  design  facilitate  ease  of  maintenance? 

3.  How  are  technical  and  functional  audits  assisted  by  the  design? 

4.  Does  the  new  design  create  any  concerns  about  training?  operations?  schedule? 

5.  What  were  the  reasons  for  deciding  on  a  software  redesign/conversion? 

6.  Describe  the  software  maintenance  plan.  What  tools  will  be  used? 

7.  How  much  design/code  can  be  retained  from  the  old  system?  Does  the  new  design 
consider  reusability  of  code? 

8.  Will  Ada  be  used  for  implementation?  If  not,  why  not? 

9.  How  will  changes  be  managed  to  ensure  that  hardware  capabilities  (capacity, 
memory,  timing,  etc.)  are  not  exceeded? 

10.  How  can  you  determine  if  sufficient  memory  and  timing  growth  capacity  have 
been  incorporated?  How  were  requirements  determined? 

11.  What  is  the  involvement  of  the  software  maintenance  organization  in  the 
development  and  testing  phases? 

12.  What  is  the  criteria  for  verifying  the  conformance  to  standards  of  hardware/ 
software/telecommunication?  How  is  this  being  accomplished? 


13.  What  is  your  plan  for  evaluating  and  managing  documentation?  How  will 
traceability  be  maintained? 

14.  Does  the  selected  design  satisfy  all  the  needs?  What  was  the  basis  for  rejecting  the 
other  designs?  What  was  the  relative  importance  of  technical,  operational,  and 
economic  factors? 

15.  Does  the  design  avoid  obsolescence  of  computer  equipment  and  software?  How? 

16.  Does  the  new  design  employ  required  standards? 

17.  Does  the  design  provide  a  capability  for  audit?  Are  functional  and  technical 
integration  requirements  specified? 

18.  What  trade-off  issues  were  addressed?  What  were  the  considerations  leading  to 
the  decision? 

19.  What  software  engineering  methodology  will  be  used? 

4.14  DEMONSTRATIONS 

These  questions  must  be  answered  at  milestones  I  and  II. 

1.  What  demonstrations  were  considered  in  order  to  verify  concept/functional 
satisfaction? 

2.  Describe  the  efforts  to  bound  the  function/concept  for  the  demonstration.  What 
are  the  constraints  and  assumptions? 

3.  Can  functional  performance  baselines  be  adequately  established?  If  not,  can 
modeling  and  simulation  assist  in  establishing  functional  performance  baselines? 

4.  If  no  demonstration  is  necessary,  has  the  concept  been  verified  as  sound;  that  it 
could  perform  in  an  operational  environment  and  provide  a  basis  for  a  final 
selection?  What  were  the  determining  factors  in  concluding  that  a  demonstration 
was  unnecessary? 

4.15  TEST  AND  EVALUATION  (T&E) 

These  questions  must  be  answered  at  milestones  I,  II,  and  III. 

1.  Have  requirements  for  testing,  evaluating,  and  certifying  been  identified  for  each 
alternative? 

2.  Has  a  testing  manager  been  appointed?  Who  writes  the  Test  Plan? 

3.  Describe  the  performance  measuring  criteria.  How  are  data  being  obtained  and 
how  is  performance  being  evaluated? 

4.  What  testing  tools  are  being  used  and/or  being  planned  for? 

5.  Has  consideration  been  given  for  independent  testing?  What  were  the  key  factors 
in  your  decision  for  or  against  independent  testing? 


6.  Describe  the  program  efforts  for  conducting  the  workload  analysis.  How  are  both 
current  and  projected  workloads  quantified  and  characterized?  How  will  you 
ensure  that  the  test  data  are  representative  of  the  total  range  of  data? 

7.  Describe  the  program  plan  for  the  use  of  a  Live  Test  Demonstration  (LTD)  or 
benchmark  testing.  Have  personnel  been  identified  and  trained  for  this  ta  ;k?  What 
special  tasks  must  be  performed? 

8.  Describe  how  the  concept  of  early  detection  of  deficiencies  is  being  supported. 

9.  What  sites  will  undergo  testing?  What  is  the  basis  for  your  decision? 

10.  What  percentage  of  the  errors  discovered  in  testing  were  due  to  changing 
requirements  versus  programming  errors?  How  is  this  being  managed? 

11.  How  will  the  overall  system  quality  be  determined? 

12.  What  are  your  plans  for  correcting  all  deficiencies  discovered  in  the  testing 
process? 

13.  Has  the  delivered  code  been  verified  to  conform  to  the  original  software  design? 
Does  the  code  satisfy  the  requirements? 

4.16  TRANSITION 

These  questions  must  be  answered  at  milestones  I,  II,  and  III. 

1.  What  is  your  transition  plan  relating  to  hardware,  software,  and  telecommunica¬ 
tions? 

2.  What  procedures  have  been  taken  to  prepare  the  equipment  site  for  the  new 
hardware?  What  happens  to  the  old  hardware? 

3.  Have  you  considered  the  use  of  a  pilot  installation?  If  not,  why  not?  If  so,  what  are 
the  goals  of  the  pilot? 

4.  Describe  your  plan  as  it  pertains  to  hardware  acceptance,  software  acceptance, 
and  telecommunications  acceptance. 

5.  How  will  the  status  quo  be  maintained  until  transition  time? 

6.  How  will  transition  occur  from  contractor  developer  to  Government?  From 
Government  to  user? 

7.  When  will  tumover/cutover  occur?  What  are  the  preliminary  actions  required? 

8.  What  is  the  plan  to  transfer  maintenance  activities  from  the  developer  to  the 
application  maintenance  activity?  What  is  the  plan  to  transfer  operations  and  data 
base  support  to  the  technical  support  activity? 

9.  What  are  the  plans  to  transfer  documentation  to  the  user  and  support  activities? 

10.  How  will  software  be  supported  in  the  field? 

11.  What  contractor  warranties  exist?  How  will  they  be  managed? 


4.17  INTEGRATION 


These  questions  must  be  answered  at  milestones  I,  II,  and  III. 

1.  What  organization  will  integrate  and  coordinate  the  contractor  development  effort? 
Describe  its  roles  and  responsibilities. 

2.  What  is  the  level  of  cooperation  between  contractors  and  government?  How  is  this 
being  managed? 

3.  Describe  the  technical  and  functional  aspects  contained  in  the  program’s 
Integration  Plan. 

4.  How  will  hardware  and  software  be  integrated  and  tested?  What  are  the  plans  and 
schedule  for  resolving  integration  problems? 

5.  What  are  the  integration  issues  between  the  developing  system  and  the  system  it 
will  replace? 

6.  What  are  the  integration  issues  between  the  developing  systems  and  those  systems 
external  to  it? 

7.  Are  there  divided  responsibilities  between  the  Government  and  the  contractor(s) 
for  system  development?  testing?  implementation?  If  so,  who  is  responsible  for 
overall  system  integration? 

4.18  IMPLEMENTATION 

These  questions  must  be  answered  at  milestones  I,  II,  and  III. 

1 .  What  level  of  improvements  are  continuing  to  be  made  under  the  old  system? 

2.  Who  will  draft  lessons  learned  after  deployment? 

3.  Have  maintenance  costs  and  support  for  overseas  environments  been  considered? 
Have  the  maintenance  plans  been  developed,  approved,  and  costed? 

4.  How  was  technical  adequacy  validated?  Who  performed  the  validations? 

5.  What  are  the  post-deployment  plans  for  periodic  re-evaluation  of  the  new  system? 
Will  such  re-evaluations  be  conducted  piecemeal? 

6.  What  is  the  phasing  of  hardware,  software,  and  telecommunications  into  the 
production  environment? 

7.  What  is  the  assessment  of  costs  actually  experienced  to  these  cost  estimated  at  the 
onset? 

8.  What  are  the  issues  addressed  in  the  detailed  implementation  plan? 

9.  What  are  your  plans  for  creating  and  verifying  the  operational  data  bases(s)? 
What  are  your  plans  for  creating  and/or  converting  data  files? 

10.  Have  plans  been  made  for  delivery?  test  and  acceptance?  Is  the  schedule 
adequate?  How  much  slippage  can  occur  without  seriously  impacting  on  the 
development  process? 


CHAPTER  FIVE 
THE  PROGRAM  MANAGER 


5.0  BACKGROUND 

The  Office  of  Management  and  Budget  (OMB)  Circular  A- 109  states  that  a  Program 
Manager  (PM)  will  be  designated  for  each  major  system  acquisition  program  and  that  the 
PM  must  “have  an  understanding  of  user  needs  and  constraints,  familiarity  with 
development  principles,  and  requisite  management  skills  and  experience.”  According  to 
DoDD  7920.1,  the  head  of  the  DoD  Component  must  appoint,  or  approve  the 
appointment  of,  a  Project  Manager  and  must  write  a  charter  specifying  the  PM’s 
“authority,  responsibility,  and  accountability  for  accomplishing  approved  program 
objectives.”  The  PM  should  serve  “long  enough  to  provide  continuity  and  personal 
accountability.”  These  instructions  are  amplified  in  ASD(C)  memorandum,  dated 
13  August  1981,  “Automated  Information  Systems  Covered  by  Life  Cycle  Management 
Policies”  (see  Appendix  C).  This  Chapter  discusses  PM  tasks  and  charter  characteristics. 

5.1  APPOINTMENT  OF  PROGRAM  MANAGER 

As  soon  as  possible  after  the  Mission  Element  Need  Statement  (MENS)  has  been 
approved,  the  Service  should  designate  a  PM.  It  is  essential  that  the  PM  participate  in  the 
consideration  of  alternatives  and  thoroughly  understand  the  constraints  that  may  exist  on 
planned  demonstration  and  validity  activities. 

The  PM  provides  continuity  and  direction  to  the  program  and  should: 

•  Serve  as  the  single  official  to  provide  daily  direction,  supervision,  and  control  of 
the  Automated  Information  Systems  (AIS)  and  hold  authority  with  responsibility 

•  Stay  long  enough  to  carry  the  AIS  development  from  inception  to  operation  or  at 
least  from  one  milestone  to  another; 

•  Be  an  experienced  manager  with  a  multidisciplinary  background  and  the  ability  to 
communicate  within  the  DoD  Components,  central  management  agencies,  and 
Congressional  committees; 

•  Have  experience  in  applying  information  technology  to  functions  similar  to  those 
addressed  in  the  MENS; 

•  Have  project  management  training  such  as  the  Program  Managers  Course  at  the 
Defense  Systems  Management  College;  and 

•  Have  a  fundamental  grasp  of  DoD  acquisition  regulations,  policies,  and  budgetary 
processes. 

5.2  PM  CHARTER 

As  a  part  of  the  appointment  of  a  PM,  the  Service  shall  approve  a  formal  charter 
delineating  the  PM’s  authority,  responsibility,  and  accountability.  This  charter  serves  as  a 
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written,  individualized  understanding  between  the  PM  and  the  oversight  authority  in  the 
DoD  Component.  For  major  AIS  developments,  the  charter  should  originate  from  the 
DoD  Component  head;  for  joint  service  AIS,  the  charter  should  originate  from  the  Deputy 
Secretary  of  Defense  or  other  OSD  official.  The  charter  should  be  reviewed  periodically 
for  currency  and  adequacy.  The  issuing  agency  retains  the  authority,  responsibility,  and 
accountability  for  any  matter  not  specified  in  the  charter. 

Typically  a  charter  should  provide  the  following  information: 

•  Name  of  the  PM; 

•  Program  mission; 

•  Reporting  channels; 

•  Special  reporting  requirements; 

•  Interfaces  and  other  agencies  involved  in  the  program; 

•  Support  to  be  provided  to  the  PM; 

•  Peculiar  relationships  not  covered  in  regulations; 

•  PM’s  authority; 

•  Parts  of  program  for  which  PM  is  responsible; 

•  Special  instructions; 

•  Structure  of  PM  office  and  PM  organization;  and 

•  Conditions  under  which  the  PM  will  phase-out  of  the  project. 
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APPENDIX  A 


REVISIONS  TO  MAJOR  AIS  APPROVAL  PROCESS 


ASSISTANT  SECRETARY  OF  DEFENSE 


comptmollin 


WASHINGTON.  OC-  20S0I 


2  9  JUN  1983 


MEMORANDUM  FOR  SECRETARIES  OF  MILITARY  DEPARTMENTS 
DIRECTORS  OF  DEFENSE  AGENCIES 

SUBJECTS  Revisions  to  Major  Automated  Information  Systems 
(AIS)  Approval  Process 


The  life  cycle  management  (LCM)  policy  for  automated 
information  systems  was  issued  to  improve  the  development  and 
operation  of  large  complex  systems  and  to  define  a  management 
process  for  the  review  and  approval  of  these  systems.  The 
basic  LCM  philosophy  of  maximising  the  functional  utility  of 
systems#  and  managing  and  costing  systems  from  inception  to 
termination  remains  sound#  and  this  philosophy  will  continue  to 
be  stressed.  At  the  same  time#  we  believe  the  management 
process  requires  refinement#  in  light  of  the  current 
Departmental  thrust  toward  streamlining  systems  acquisition 
processes  and  strengthening  planning  and  competition. 

The  attached  guidance  reflects  revisions  to  the  approval 
process  for  major  automated  information  systems  as  described  in 
DoD  Instruction  7920.2#  "Major  Automated  Information  Systems 
Approval  Process."  In  essence#  the  new  guidance! 

-  Calls  for  more  rigorous  mission  analysis  and  functional 
planning. 

-  Provides  for  a  more  streamlined  acquisition  process  by 
reducing  the  number  of  OSD  level  reviews. 

-  Stresses  increased  competition  in  system  acquisition 
strategies . 

-  Emphasises  the  importance  of  using  sound  financial 
management  practices. 

One  of  our  major  initiatives  during  the  next  fiscal  year 
will  be  to  consider  approaches  for  establishing  a  stronger 
linkage  between  the  AIS  decision  process  and  the  Planning# 
Programming  and  Budgeting  System  (PPBS).  In  this  regard#  we 
will  continue  to  seek  your  views  and  comments  through  your 
representatives  on  the  Information  Resources  Management  Systems 
Council . 


X  request  your  cooperation  in  ensuring  that  the  enclosed 
guidance  is  incorporated  into  your  management  process  at  all 
levels. 


Enclosure 


mean  furitano  ^ 
assistant  secretary  or  defense 
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A.  SCOPE 

1.  This  guidance  applies  to  major  automated  information 
systems  as  defined  in  DoD  Directive  7920.1*  "Life  Cycle 
Management  of  Automated  Information  Systems  (AIS)*"  and  the 
associated  approval  process  as  described  in  DoD  Instruction 
7920.2*  "Major  Automated  Information  Systems  Approval  Proceas." 

2.  DoD  Components  are  encouraged  to  apply  this  guidance  to 
other  large  information  technology  efforts. 

B.  OBJECTIVES . 


The  objectives  of  this  guidance  are  tot 

1.  Emphasise  the  importance  of  performing  continuing 
mission  analyses  and  functional  planning*  and  the  integration 
of  major  AIS  acquisition  plans  into  DoD  Component  planning 

systems • 

2.  Promote  increased  competition  in  the  acquisition  of  AIS 
software*  hardware,  and  services  through  early  identification 
of  needs,  early  establishment  of  user  and  technical  teams  to 
prototype  best  solutions  to  needs,  and  the  use  of  sound* 
systematic  plans  for  satisfying  these  needs. 

3.  Streamline  the  AIS  acquisition  process  by  selective  and 
controlled  decentralisation  of  systems  approval  authority. 

4.  Strengthen  the  use  of  sound  financial  management 
practices  in  the  acquisition  of  AIS  by  encouraging  the  use  of 
more  comprehensive  lease/purchase  analyses  and  sound  cost 
accounting  and  budgeting  practices. 

C.  ACQUISITION  MANAGEMENT  PRINCIPLES 

1.  Improvements  in  planning  and  resources  management  shall 
be  the  basis  for  providing  DoD  Components  at  all  levela  with 
more  autonomy  and  responsibility  in  AIS  acquisitions. 

2.  The  Mission  Analysis/Project  Initiation  decision  for  a 
major  AIS  shall  be  retained  at  the  OSD  level.  Consistent  with 
the  principle  of  controlled  decentralisation*  the  OSD  staff  may 
elect  to  delegate  all  or  some  of  the  remaining  AIS  milestone 
decisions  to  the  DoD  Components.  The  extent  of  delegation  will 
depend  on  the  quality  of  mission  analyses  and  functional 
planning*  the  use  of  sound  financial  management  practices*  and 
the  extent  of  competition.  In  support  of  this  principle*  DoD 


Components  srs  encouraged  to  further  delegate  approval 
authority  to  the  lowest  appropriate  organisational  level  which 
is  feasible  and  practical* 

3.  Reliance  on  industry  and  state-of-the-art  system 
development  tools  for  technical  solutions  to  problems  and 
cosipetitive  practices  shall  be  used  to  the  maximum  extent 
practicable  to  ensure  the  cost-effectiveness  and  functional 
utility  of  systems*  In  this  regard*  the  use  of  prototype 
systems  is  encouraged  since  they  may  assist  in  identifying  the 
range  of  alternative  solutions  to  the  requirement. 

4*  Methods  of  financing  AIS  acquisitions  shall  seek  to 
assure  that  systems  are  acquired  at  the  lowest  total  overall 
cost  (LTOC) .  Lease/purchase  analysis  shall  be  performed  to 
assist  in  selecting  the  LTOC  alternative.  Purchase  may  be  the 
best  course  When  requirements  are  stable.  When  requirements 
are  unstable  and  maximum  flexibility  is  required,  leasing 
arrangements  may  be  the  best  course.  However,  long-term 
leasing  usually  will  represant  an  inappropriate  management 
practice. 

D.  MILESTONE  DECISIONS  AND  APPROVALS. 

1.  In  preparation  for  the  Milestone  0  decision,  DoD 
Components  shall  submit  a  Mission  Element  Need  Statement  (MENS) 
as  described  in  DoD  Directive  7920.1.  The  development  of  the 
MENS  should  be  integrated  in  the  Component  planning, 
programming  and  budgeting  process  at  the  earliest  time 
possible.  The  submission  of  the  MENS  may  be  made  at  any  time; 
however,  in  the  interest  of  early  planning,  it  is  advisable 
that  the  MENS  be  submitted  in  conjunction  with  the  POM  process, 
where  practicable.  Upon  completion  of  the  processing  and 
approval  of  the  MENS,  a  System  Decision  Memorandum  (SDK)  shall 
be  prepared  and  become  the  means  for  communicating  the  OSD 
approval/decision,  and  for  providing  other  appropriate 
guidance.  The  SDN  wf 11  provide  official  sanction  for  a  major 
AIS  and  authorise  the  DoD  Component  to  initiate  the  next 
acquisition  phase. 

2.  Approval  at  Milestone  1  will  also  be  retained  at  the 
OSD  level  in  accordance  with  DoD  Directive  7920.1.  However, 
this  milestone  decision/approval  may  be  delegated  to  the  DoD 
Component  if  (a)  planning  continues  to  be  comprehensive  and 
sound,  (b)  prototype  action,  as  appropriate,  has  been  taken  to 
ensure  the  most  effective  alternative  for  the  requirement  has 
been  selected,  (c)  the  system  continues  to  be  developed  within 
established  schedules  and  costs,  and  (d)  program  management 
structure  and  acquisition  strategy  remain  sound  and  stable. 


3.  Normally,  Milestone  IZ  and  Milestone  ZZZ  review  and 
approval  will  be  delegated  to  the  DoD  Components. 

Documentation  requirements  for  these  milestones  shall  continue 
to  be  developed  and  updated  in  accordance  with  DoD  Instruction 
7920.2. 

4.  Throughout  the  A1S  development  process,  both  the  OSD 
and  Component  staffs  should  work  to  maintain  the  free  exchange 
of  information  and  open  channels  of  communication  regarding  XIS 
progress  and  issues.  The  OSD  staff  will  conduct  selected 
reviews  of  information  technology  acquisitions  and  management 
under  the  Information  Resources  Management  (IRM)  Review 
Program,  and  review  AIS  resource  requirements  through  AIS 
exhibits  submitted  in  conjunction  with  the  annual  Information 
Technology  Budget.  Usually,  OSD  reviews  will  occur  in  the 
earlier  phases  of  the  AIS  life  cycle  and  provide  a  basis  for 
further  delegations.  These  reviews  will  focus  on  functional, 
technological  and  financial  planning ;  program  management 
structure;  acquisition  strategy;  and  telecommunications, 
security,  and  readiness/survivability  requirements. 

S.  PLANNING  AND  MISSION  ANALYSIS 


A  major  factor  in  effective  planning  is  continuing 
analyses  of  assigned  mission  areas.  DoD  Components  shall 
conduct  continuing  analyses  of  their  assigned  mission  areas  to 
identify  deficiencies,  or  to  determine  more  effective  means  of 
performing  assigned  tasks.  In  conjunction  with  these  analyses, 
DoD  Components  shall  also  keep  regularly  informed  of  industry 
advances  and  information  technology  trends  to  identify 
opportunities  to  take  advantage  of  modern,  cost-effective 
technology.  Specific  eources  for  technology  assessments  may 
include  the  five  year  plan,  required  by  the  Paperwork  Reduction 
Act  and  published  by  OMB  in  consultation  with  GSA,  and  the 
National  Bureau  of  Standards.  Requirements  for  new  AIS,  or 
major  changes  to  existing  AIS,  may  be  identified  as  a  result  of 
these  analyses  and  assessments. 
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THE  DERJTY  SECRETARY  OF  DEFENSE 


WASHINGTON.  D.C.  20)01 


2  0  FEB  1986 


MEMORANDUM  FOR  SECRETARIES  OF  THE  MILITARY  DEPARTMENTS 

UNDER  SECRETARIES  OF  DEFENSE 
ASSISTANT  SECRETARIES  OF  DEFENSE 
DIRECTORS  OF  THE  DEFENSE  AGENCIES 
DIRECTOR  OF  THE  JOINT  STAFF,  OJCS 

SUBJECT:  Management  Responsibility  for  General  Purpose 
Automatic  Data  Processing  (ADP)  Systems 


During  the  FY  86  Appropriations  Hearings,  the  Congress 
questioned  the  structure  and  process  being  employed  by  the 
Department  to  manage  its  general  purpose  ADP  programs.  While 
the  Congress  recognized  the  importance  of  ADP  to  the  DoD, 
Congress  did  request  that  DoD  review  and  consolidate  its 
oversight  structure  for  general  purpose  ADP. 

Since  I  am  satisfied  that  our  Major  Automated  Information 
System  Review  Council  (MAISRC)  process  is  working  well,  I  have 
determined  that  the 'policy  responsibility  for  all  DoD  general 
purpose  ADP  systems  shall  be  consolidated  under  the  Assistant 
Secretary  of  Defense  (Comptroller).  L. believe  this  clarifies 
and  streamlines  our  OSD  review  process,  and  at  the  same  time 
supports  the  goals  of  the  Warner  Amendment.  The  Under 
Secretary  of  Defense  for  Research  and  Engineering  will  continue 
to  provide  policy  for  computers  embedded  in  weapons  systems. 

The  ASD(C)  will  work  in  conjunction  with  you  to  ensure 
that  a  consistent  management  and  policy  framework  exists  to 
address  this  vital  mission  support  area.  The  ASD(C)  should 
immediately  take  those  actions  necessary  to  establish  a  single 
policy  and  oversight  framework  to  manage  DoD's  general  purpose 
ADP  programs. 


William  H.  Taft,  IV 
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ASSISTANT  SECRETARY  OF  DEFENSE 


WASHINGTON.  DC.  20301 


1  3  AUG  1981 


# 


JMPTftOLLCft 


# 


m 


memorandum  for  secretaries  of  the  military  departments 

DIRECTORS  OF  DEFENSE  AGENCIES 


SUBJECT:  Automated  Information  Systems  Covered  by  Life 
Cycle  Management  Policies 


Strong  project  management  during  the  entire  system  life 
cycle  is  an  essential  requirement  of  DoD  Directive  7920.1, 
"Life  Cycle  Management  of  Automated  Information  Systems 
(AIS) • "  This  requirement  is  intended  to  ensure  that  both 
developmental  and  operational  AISs  are  well  managed  and  that 
accountability  is  clearly  affixed  as  a  prerequisite  to  large 
resource  expenditures. 


The  Defense  Audit  Service,  in  Report  No.  81-075  on  the 
implementation  of  DoD  life  cycle  management  (LCM)  policies, 
found  that  the  DoD  Components  were  not  establishing  project 
managers  and  were  having  difficulty  using  the  definition  of 
an  AIS  in  applying  the  policies  to  systems  currently  being 
managed.  To  remedy  this,  the  Defense  Audit  Service  recommended 
that  more  specific  instructions  be  issued  to: 


o  Identify  what  should  be  managed  under  LCM. 


o  Help  distinguish  between  the  end  of  an  operational 
AIS's  life  and  the  start  of  a  new  AIS  life  cycle. 


o  Provide  guidance  on  chartering  project  managers. 


The  attached  guidance  provides  more  explicit  guidance  for  the 
application  of  the  policies  and  concepts  in  DoD  Directive 
7920.1.  This  memorandum  also  incorporates  previous  guidance 
on  the  appointment  of  project  managers  and  the  structure  of 
project  manager  charters.  Accordingly,  my  memorandum  of 
April  20,  1981  on  "Charters  for  Automated  Information 
Systems  Project  Managers"  is  superseded  and  hereby  canceled. 


Mr.  William  B.  Ritt,  697-9068,  is  the  point  of  contact  in  my 
office  for  this  policy  guidance.  * 

■Lula 

H  Jack  R.  Boating 
Assistant  Secretary  of  Defense 
(Comptroller) 
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PURPOSE 


This  paper  provides  guidance  on: 

o  Identifying  automated  information  systems  develop¬ 
ments  that  must  be  managed  under  the  provisions  of  DoD 
Directive  7920.1,  "Life  Cycle  Management  of  Automated 
Information  Systems  (AIS)" 

o  Correlating  the  events  that  occur  in  the  life  span 
of  such  AISs  to  the  life  cycle  phase  requirements  of  DoDD 
7920.1. 

o  Developing  project  manager  charters  and  controls 
for  monitoring  AISs. 

SCOPE 

Life  Cycle  Management  ( LCM)  Application.  It  should  be  noted 
that  the  LCM  concepts  and  policies  in  DoD  Directive  7920.1 
apply  to  the  management  of  all  AISs  irrespective  of  scope  of 
the  efforts  or  their  dollar  value.' 

Pniformity.  These  guidelines  seek  to  unify  LCM  interpretations 
and  achieve  a  rational,  clear,  and  cooperative  implementation 
of. LCM  policies'  across,  a  spectrum  of  different  types  of  AIS 
developments  that  are  either  major  or  non-major  in  scope. 


AUTOMATED  INFORMATION  SYSTEM  BOUNDARIES 


Definition.  An  AIS  is  defined  in  DoD  Directive  7920.1  as  a 
* collection  of  functional  user  and  ADP  personnel,  procedures 
and  equipment  (including  ADPE)  which  is  designed,  built, 
operated  and  maintained  to  collect,  record,  process, 
store,  retrieve,  and  display  information." 

The  focus  of  managerial  concerns,  areas  of  emphasis,  goals 
and  the  resultant  achievement  strategies  varies  among  the 
D'oD  Components.  Therefore,  the  term  "automated  information 
system"  is  deliberately  defined  in  a  general  way  to  recog¬ 
nize  and  allow  for  decentralized  managerial  judgement 
ins 


o  Organizing  to  accomplish  DoD  Component  functions; 

o  Devising  means  of  performing  the  functions. 

Segmentation.  The  initial  and  evolving  segmentation  of 
total  DoD  Component  AIS  resources  into  individual  AISs  is  a 
matter  of  managerial  judgement.  Mission  area  analysis  and 
the  degree  of  design/management  integration  required  to 
ensure  effective  and  efficient  mission  performance  determine 
how  this  is  done. 

AIS  resources  should  be  divided  into  manageri&lly  coherent 
groupings,  which  may  Vary  considerably,  e.g.,  a  set  of 
service  centers  supporting  diverse  users,  a  standard 
grouping  of  computer  application  programs,  a  multi-site 
grouping  of  standard  hardware/software  to  serve  a  single 
mission. 

An  AIS,  which  represents  an  integrated  entity  from  a  design 
or  acquisition  standpoint  and  which  supports  a  common 
mission,  must  not  be  divided  into  smaller  AISs  or  projects 
in  order  to  avoid  life  cycle  management  visibility  and 
review. 


MANAGEMENT  OF  CHANGE 


Tht  Life  Cycle.  In  any  general  discussion  of  the  LCM 
process,  it  is  convenient  and  customary  to  depict  the  life 
cycle  of  an  AXS  in  the  linear  fashion  shown  in  Attachment 
1  —  a  life  cycle  with  a  beginning  and  an  end.  This  permits 
some  understanding  of  the  various  events,  and  critical 
stages  that  ensue  in  the  life  span  of  an  AXS. 

However,  the  real-life  situation  is  that  existing  AXSs  are 
continually  subjected  to  change,  usually  in  the  nature  of: 

o  Functional  changes  --  new  ideas  or  policies,  new 
techniques  or  methods,  new  legislation,  personnel  turnovers, 
new  responsibilities,  new  workload,  etc. 

o  Technological  changes  --  more  advanced  and  efficient 
equipment,  conversion  to  higher-order  languages,  installa¬ 
tion  of  data  base  management  systems,  etc. 

Thus,  the  life  cycle  is  really  a  continuum.  Xn  most  instances, 
the  "function”  being  supported  by  an  AXS  is  not  terminated, 
but  is  dynamic  and  continuous.  The  AXS  is  changed  to 
perform  new  mission-related  functions  or  to  perform  the 
same  general  functions  in  an  improved,  more  efficient 
manner. 

DoD  Directive  7920.1  recognizes  this  phenomenon  by  requiring 
that  operational  AXSs  be  reevaluated  on  a  periodic  basis  to 
assure  continued  cost/ef fectiveness. 

Also,  AXSs  that  are  being  developed  or  redesigned  must  be 
assessed  at  each  milestone  to  verify  that  the  mission  need 
is  still  valid  and  that  the  AXS  meets  cost/effectiveness 
criteria. 

The  LCM  Process.  Life  cycle  management  is  the  process  for 
administering  an  AXS  over  its  entire  life  span.  Thus,  the 
system,  comprised  of  all  its  parts,  is  what  is  managed.  Any 
.part,  if  altered  in  some  way,  will  have  some  impact  on  the 
remaining  parts  of  the  AXS.  Life  cycle  management  aims  at 
maintaining  control  over  and  managing  these  impacts  in  a 
disciplined  manner  so  that  efficient,  effective,  and  operable 
AXSs  will  result. 

Life  cycle  management  may  be  viewed  from  two  perspectives: 
o  a  managerial  decision-making  process}  or 
o  a  systems  engineering  discipline. 


9 


There  may  be  many  strategies  for  AXS  revisions  which  bypass 
regular  steps/actions  in  the  systems  engineering  process, 
for  example,  by  using  existing  ADP  equipment  "as  is”  or  by 
using  the  marketplace  to  solicit  off-the-shelf  solutions. 
Nevertheless,  the  managerial  decision-making  process  cannot 
jump  over  essential  considerations  of  mission  need,  adequacy 
of  requirements  specification,  or  readiness  for  implementa¬ 
tion. 
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Each  DoD  Component  is  encouraged  to  develop  a  schema  of 
decentralized  authority,  indicating  the  organizational  level 
at  which  AIS  projects  can  be  undertaken  without  the  approval 
of  a  higher  organizational  level.  This  matrix  chart  should 
use  dol-lar  value  ranges  of  effort  or  other  considerations  as 
criteria  for  such  decentralization  and  should  also  indicate 
whether  a  full-time  project  manager  is  required  for  a 
non-major  A2S. 


TYPES  OF  AIS  DEVELOPMENTS 

New  AIS  Developments.  The  development  of  new  AISs,  i.e., 
automation  of  a  function  or  activity  that  was  previously 
done  manually,  fits  the  classic  mold  for  application  of 
life  cycle  management  policies  in  the  linear  sequence  shown 
in  Attachment  1 • 

These  instances  require  managerial  consideration  of  all 
aspects  of  the  life  cycle  from  the  beginning. 


ADP  Equipment  Augmentation  and  Updates.  Equipment  change- 
overs  may  impact  the  remaining  parts  of  an  AZS.  Each 
situation  must  be  critically  examined  to  determine  whether 
the  change  can  be  managed  in  the  context  of  the  current  life 
cycle  phase  or  whether  the  AIS  must  be  managed  at  an  early 
phase  or  at  the  beginning. 

a.  An  equipment  augmentation  is  the  acquisition  of 
additional  capacity  or  same -capacity  replacement  of  existing 
equipment  with  faster,  cheaper  equipment.  The  requirement 
for  additional  capacity  results  from  increased  workload. 

Zt  does  not  involve  redesign  or  modification  of  functional 
specifications  or  software.  Such  acquisition,  within  the 
existing  hardware/software  architecture,  is  usually  not  a 
cause  for  going  back  to  the  beginning  of  the  life  cycle. 

However,  an  augmentation  should  be  carefully  examined  to 
determine  if  it  is  a  superficial  solution  masking  a  more 
fundamental  problem,  i.e.,  an  underlying  need  for  system 
redesign.  Redesign  cases  require  managerial  consideration 
of  all  aspects  of  the  life  cycle  from  the  beginning  (see 
section  on  "Software  Modification  and  Redesign”). 

b.  An  equipment  update-  is  an  action  to  acquire  newer 
technology  ana  make  major  changes  in  processing  methodology, 
e.g.,  the  conversion  from  batch  to  on-line  interactive 
processing.  Updates  have  significant  impacts  on  all  remaining 
pkrts  of  an  AIS,  e.g.,  software  mus.t  be  converted,  'functional 
procedures  updated,  operators  retrained.  These  updates 
require  managerial  reconsideration  of  all  aspects  of  the 
life  cycle  from  its  beginning  (see  section  on  "Software 
Modification  and  Redesign"). 
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Software  Modification  and  Redesign,  Historically,  most 
automated  information  systems  are  not  terminated  but 
continue  to  evolve  through  modification: 

o  When  this  occurs  within  the  context  of  the  initial 
concept  for  the  AIS  and  does  not  cause  the  fundamental 
architecture  or  design  to  be  redefined,  a  return  to  the 
beginning  of  the  life  c (  ole  management  process  is  not 
required. 

o  However,  some  systems  have  been  so  modified  or  have 
been  overtaken  by  technological  advances,  so  that  a  complete 
redesign  is  undertaken.  Then,  a  restart  of  the  life  cycle 
from  the  beginning  is  necessary. 

A  strategy  to  acquire  ADP  capability  which  is  based  on 
a  compatible  hardware  update  and  minimal  system  redesign  may 
be  initially  least  costly,  but  can  often  be  relatively 
expensive  over  the  entire  life  cycle  because  continued 
software  modification  costs  will  bfe  incurred.  However,  a 
strategy  to  transition  to  new  hardware,  minimizing  conver¬ 
sion  and  software  redesign,  will  likely  be  the  lowest  total 
overall  cost  alternative  if: 

o  Functional  requirements  are  projected  to  remain 
relatively  stable,  and 
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o  The  software  which  supports  these  requirements  is 
modern  and  well  documented  in  accordance  with  DoD  documenta¬ 
tion  standards,  and 

o  The  AIS  fulfills  the  requirements  of  OMB  Circular 
A-71  (Transmittal  Memorandum  #1)  with  respect  to  security. 

A  strategy  to  acquire  ADP  capability  which  stresses  software 
redesign  and  compliance  with  national  and  federal  standards 
may  be  initially  costly.  But,  these  costs  may  be  offset  by 
economies  which  can  be  achieved  through  fully  competitive 
hardware  procurements,  lower  future  software  maintenance 
costs,  and  easier  future  transition  to  hardware  of  a  different 
manufacturer.  This  strategy  is  likely  to  be  the  lowest 
total  overall  cost  alternative  over  the  long  term  if: 

o  Functional  requirements  have  not  been  reanalyzed  for 
continued  mission  effectiveness. 

o  The  current  software  is  not  consistent  with  new 
technological  capabilities  and  is  not  written  in  a.  higher 
order  language  (e.g.,  ANSI  COBOL  74,  ANSI  FORTRAN  77)  and 
the  documentation  is  incomplete; 

o  The  current  software  does  not  fulfill  the  security 
requirements  of  OMB  Circular  A-71  (Transmittal  Memorandum 
«1). 


CONTROLS  FOR  PROGRESS  MONITORING 

Project  Manager.  A  project  manager  should  be  designated  and 
chartered  for  each  AIS  as  soon  as  possible  after  the  mission 
element  need  statement  has  been  approved. 

Installation  of,  or  significant  revision  to,  an  AIS  for 
multiple  sites  should  be  undertaken  by  a  chartered 
project  manager  when: 

o  standard  software  is  to  be  centrally  designed, 
programed,  and  maintained  for  all  of  the  installations 
concerned 

o  such  procurement  is  justified  on  the  basis  of  cost/ 
effectiveness,  operational  efficiency,  and  a  commonality  of 
requirements. 

Likewise,  acquisition  of  ADP  equipment  for  installation  at 
designated  service  centers,  supporting  a  wide  range  of  users 
with  diverse  computer  applications,  should  be  managed  by  a 
chartered  project  manager.  The  justification  for  augmenta¬ 
tion  or  update  of  ADPI/teleprocessing  support  can  then  be 
related  to  the  consolidated,  but  separately  identified, 
workload  requirements. 

The  project  manager  of  a  major  or  joint-service  AIS  should 
devote  full-time  attention  to  the  AIS  ands 

o  be  designated  as  the  single  official  to  provide 
daily  direction,  supervision,  and  control  of  the  AIS  and 
be  given  authority  commensurate  with  assigned  accountability 
and  responsibility. 

o  have  sufficient  tenure  to  provide  continuity  to 
carry  the  AIS  development  from  inception  to  operational 
status. 

o  be  an  experienced  manager  with  a  multidisciplinary 
background  and  the  ability  to  communicate  within  the  DoD 
Components,  central  management  agencies,  and  Congressional 
committees. 

o  have  experience  in  applying  information  technology 
to  enhance  functions  similar  to  those  addressed  in  the 
mission  element  need  statement. 

o  have  project  canagement  training,  e.g«,  for  project 
managership  of  major  AISs,  preferably  have  satisfactorily 
cofop. ated  the  Program  Managers  Course  at  the  Defense  Systems 
Management  College)  for  non-major  AISs,  preferably  have 
satisfactorily  completed  the  Project  Management  Course  at 
the  DoD  Computer  Institute. 

o  have  a  fundamental  grasp  of  DoD  acquisition  regula¬ 
tions  and  policies. 


Project  Manager  Charter*  The  project  manager  charter, 
which  is  developed  specifically  for  each  AIS,  serves  as  a 
written,  individualized  understanding  between  the  project 
manager  and  the  appropriate  oversight  authority  in  the  DoD 
Component.  This  charter  should  set  forth  the  responsibil¬ 
ity,  authority,  and  accountability  of  the  project  manager 
Typical  charter  elements  are  shown  in  Attachment  2. 

o  For  major  AZS  developments,  the  project  should  be 
chartered  by  the  Bead  of  the  DoD  Component. 

o  Joint-service  AISs  should  be  chartered  by  the 
Deputy  Secretary  of  Defense  or  someone  designated  at  the  OSD 
level. 

o  For  non-major  AISs,  the  project  should  be  chartered 
by  an  official  at  the  Military  Department  Assistant  Secretary 
level  or  a  comparable  level  in  a  Defense  Agency,  or  by 
the  Commander  at  a  subordinate  level  where  the  AIS  serves 
only  that  level. 


Program  Coordination*  Requirements  for  the  interface  of 
two  or  more  AZS  developments  may  be  of  such  importance, 
complexity  and  magnitude  as  to  warrant  the  employment  of 
special  management  arrangements.  In  such  cases,  the  Bead 
of  the  PoD  Component  should  establish  and  charter  program 
coordination  offices. 

o  Each  AIS  within  such  a  program  should  be  budgeted 
separately  and  managed  under  the  life  cycle  principles  in 
DoD  Directive  7920.1. 

« 

o  Significant  directly-identifiable  program  costs 
could  be  budgeted  separately  from  those  of  the  individual 
AISs  in  the  program,  e.g.,  program  administration  costs, 
cost  of  test-bed  ADP  equipment  that  will  be  used  for  testing 
software  for  a  number  of  AISs. 

The  group  of  projects  or  "program”  is  not  considered  an 
AIS,  per  se.  However,  the  total  program  should  be  reviewed 
at  designated  decision  points,  which  have  been  specified  in 
a  program  coordination  management  plan,  to  determine  if  the 
program  and  its  AISs  are  progressing  as  planned.  Because 
there  will  be  a  number  of  AISs  within  a  program,  the  review 
points  established  for  the  program  need  not  exactly  correlate 
to  the  established  milestones  required  for  any  of  the  AISs. 
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AiS  Review  Group*  To  ensure  policy  control  during  the 
entire  course  of  an  AIS  development,  a  senior  management 
review  group  should  be  formed  to  review  progress  and  make 
decisions  at  each  life  cycle  milestone  decision  point.  This 
group  is.  the  decentralized  adaptation  of  the  OSD  review 
structure  Contained  in  DoD  Instruction  7920.2,  "Major 
Automated  Information  Systems  Approval  Process." 

i 

o  For  major  AIS  development  projects  which  would 
ordinarily  meet  the  threshold  for  milestone  approval  at  the 
OSD  level,  but  which  have  been  delegated  for  DoD  Component 
approval,  milestone  approval  should  be  accomplished  by  a 
group  chaired. by  a  Military 'Department  Assistant  Secretary 
or  comparable  level  in  a  Defense  agency. 

o  For  non-major  AIS  development  projects,  milestone 
approvals  should  be  accomplished  at  a  senior  organizational 
level,  commensurate  with  the  life  cycle  cost  of  the  project. 

The  group  should  be  comprised  of  the  appropriate  level 
managers  from  the  ADP  and  telecommunication  areas  and  from 
the  functional  area(s)  served  by  the  AIS.  Often,  it  may  be 
beneficial  to  have  representatives  from  other  areas  such  as 
legal,  auditing,  and  manpower,  in  attendance  at  milestone 
decision  meetings  when  the  need  dictates. 

Dependent  on  authority .delegated  by  the  Bead  of  the  DoD 
Component,  the  group  should  initiate,  continue,  redirect  or 
terminate  the  project  and  should  consider  any  strategic 
matters  affecting  the  project!  provide  overall  policy 
direction  and  reinforce  both  accountability  and  primary 
management  controls.  It  should  meet  at  each  LCM  milestpne 
and  at  intermediate  in-process  review  points,  if  the  time 
between  milestones  is  protracted. 


LIFE  CY®  MANAGEMENT 

PHASES  -  MILESTONES  -  DOCUMENTATION 


Attachment  2 
1 3  AUS  1981 


ELEMENTS  OF  A  PROJECT  MANAGER  CHARTER 


Careful  attention  must  be  paid  to  any  unique  characteristics 
of  an  AIS  development  project  so  that  the  project  manager 
charter  is  tailored  to  the  project  being  undertaken.  The 
fpllowing  areas  typically  represent  the  topics  that  must  be 
considered  in  constructing  the  individualized  project 
manager  charter. 

Project  Identification 

o  Cite  the  title  and  the  short  name  of  the  AIS.  Names 
that  give  some  ready  reference  to  the  function  being 
served  and  the  initial(s)  of  the  DoD  Component  should 
be  used. 

o  Specify  frequency  at  which  the  charter  will.be  reviewed 
and  updated. 

Mission  and  Objectives 

o  State  in  terms  of  mission  need  and  cite  extent  of 
authority  to  consider  all  alternative  solutions  to 
fulfill  the  need. 

o  Delineate  the  scope  of  the  project  in  terms  such  as, 
number  of  installations  affected,  boundary  of  the 
mission  encompassed  by  the  project,  the  specific 
functlon(s)  to  be  excluded  from  the  project,  inter¬ 
face  requirements,  etc. 

o  State  specific  accomplishments  to  be  sought,  estimated 
timeframes,  and  deliverable  end  products  required,  for 
which  the  project  manager  is  accountable. 

Responsibilities  and  Accountability 

o  Project  Manager 

-  Provide  specific  detail  that  equates  to  a  job 
description. 

-  Include  any  special  responsibilities  that  are 
peculiar  to  the  project  and  any  authorized  waivers 
from  current  regulations. 

-  Specify'  reporting  and  recommendatory  responsibili¬ 
ties  when  cost,  schedule,  or  technical  performance 
thresholds  are  breached. 


o  Users 

-  Cite  responsibilities  of  user  field  activities  and 
other  commands  or  organizations  within  the  DoD 
Component. 

-  Specify  source  of  requirements  inputs  from  users 

-  and  the  process  for  modification  of  requirements 
by  users. 

Authorities 

o  Delineate,  as  applicable,  the  extent  of  latitude  in: 

-  Controlling  project  resources 

•  Contacts  with  other  Federal  Agencies,  the  Congress, 
industry,  etc. 

-  Tasking  other  DoD  Components  and  consummating 
interservice  support  agreements  and  memoranda  of 
understanding 

-  Creating  subordinate  offices 

-  Obtaining  consulting  or  commercial  ADP  services 

-  Authorizing  per  diem,  travel,  and  overtime 

-  Signing  Agency  Procurement  Requests  to  GSA  and 
making  sole  source  selection 

o  Define  authority  for  performance  appraisal  of  team 
members,  designated  to  support  the  project  management 
office,  from  a  separate  support  organization. 

Relationships  and  Channels  of  Communication 

o  Establish  the  channel  of  reporting  for  accomplishment 
of  the  project  to  include: 

-  Reporting  and  approval  levels  for  key  milestones 

-  Frequency  and  level (s)  of.  progress  reporting  and 
internal  team  reviews 

o  Describe  relationships  to: 

-  Chartering  authority 

-  Steering  and  advisory  groups 

o  Establish  a  requirement  for  independent  audit  or 
assessment:  of  economic  analyses. 


Organization  and  Location 

o  Indicate  name  and  grade/rank  of  the  Project  Manager. 

o  Establish  required  makeup  of  the  project  management 
team  and  depict  organizational  chart  of  the  project 
management  offices 

-  Functional  or  work  breakdown  assignments 

-  Initial  staffing 

o.  Designate  technical#  administrative#  and  contracting 
support  functions  and  user  representation. 

o  Indicate  location  of  project  management  office. 

Project  Transition/Disestablishment 

o  Specify  event  at  which  the  project  management  office 
will  be  terminated  or  circumstances  under  which  it 
will  continue  after  the  AIS  project  is  developed  and 
tested. 

o  Delineate  hardware  and  software  maintenance/ 

modification  responsibility#  if  any#  after  the  AIS 
project  is  installed. 
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APPENDIX  D 


MANAGEMENT  OF  GENERAL  PURPOSE  ADP  SYSTEMS 


ASSISTANT  SECRETARY  OF  DEFENSE 


COMPTROLLER 


WASHINGTON.  D  C.  20101 


I 

i 

2  6  MAR  1936  I 


MEMORANDUM  FOR  SECRETARIES  OF  THE  MILITARY  DEPARTMENTS 
CHAIRMAN,  JOINT  CHIEFS  OF  STAFF 
UNDER  SECRETARIES  OF  DEFENSE 
ASSISTANT  SECRETARIES  OF  DEFENSE 
DIRECTORS  OF  THE  DEFENSE  AGENCIES 


SUBJECT:  Management  of  General  Purpose  Automatic  Data 
Processing  (ADP)  Systems 


The  Deputy  Secretary's  memorandum  of  February  20,  1986, 
directed  that  my  office  assume  consolidated  policy  oversight 
for  all  general  purpose  ADP  systems.  This  action  was  taken  to 
clarify  and  streamline  the  OSD  ADP  management  and  oversight 
structure  for  the  Department. 


There  are  three  steps  which  should  be  taken  quickly  to 
begin  this  consolidation  and  meet  Mr.  Taft's  guidance.  First, 
all  general  purpose  ADP  systems  will  be  expected  to  follow  the 
Life  Cycle  Management  Policy  described  in  DoDD  7920.1.  Second, 
all  major  general  purpose  ADP  systems,  including  Warner  exempt 
2  systems,  subject  to  OSD  review  will  be  reviewed  by  the  Major 
9  Automated  Information  System  Review  Council.  Third,  each 

Component  should  have  an  accountable,  executive  level  review  . 
process  in  place  and  operating  which  includes  full  involvement 
of  ADP,  telecommunications,  and  functional  management.  This 
review  process  should  be  based  on  the  principles  of  DoDD  7920.1 
and  should  ensure  that  accelerated  acquisitions  are  achieved  by 
establishing  a  firm  management  base  for  each  program.  An 
effective  Component  oversight  process  is  essential  to  achieving 
further  streamlining  through  increased  delegations. 


While  it  is  not  practical  to  transition  immediately 
ongoing  Warner  exempt  programs  to  strict  adherence  to  DoDD 
7920.1,  planning  and  implementation  of  this  transition  must 
occur  as  rapidly  as  possible.  Other  needed  policy  adjustments 
will  be  developed  in  the  near  future  including:  Warner 
Amendment  determinations,  delegations  for  management  of 
intelligence  and  cryptographic  systems,  standards,  and 
programing  languages.  We  plan  to  act  on  these  areas 
aggressively,  but  will  do  so  in  conjunction  with  your  staffs. 


We  will  be  forwarding  shortly,  for  Component  review  and 
comment,  the  newest  list  of  major  automated  information .systems 
for  OSD  and  Component  oversight.  The  list  will  reflect  these 
basic  consolidation  actions. 

TidvJ:  f-jcQ/h'i 

Robert  W.  Helm  < 

Assistant  Secretary  of  Defense 
(Comptroller) 
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DELEGATION  OF  OVERSIGHT  RESPONSIBILITY  FOR  AIS 


xirrmun 


ASSISTANT  SECRETARY  OF  DEFENSE 

WASHINGTON.  DX.  20 >01 


2  APR  1988 


MEMORANDUM  FOR  SECRETARIES  OF  MILITARY  DEPARTMENTS 
DIRECTORS  OF  DEFENSE  AGENCIES 

SUBJECT:  Delegation  of  Oversight  Responsibility  for  Automated 
Information  Systems 


ft 


In  the  FY  SB  House  Appropriations  Report*  the  Congress 
provided  the  DoD  with  specific  guidance  on  Delegation  of 
Oversight  Responsibility  for  systems  under  review  by  Major 
Automated  Information  System  Review  Council  (MAISRC).  Congress 
indicated  that  it  "expects  each  component  to  aggressively 
adhere"  to  certain  specified  management  responsibilities  and 
also  to  "ensure  that  requirements  are  valid  and  controlled, 
that  the  proposed  program  strategy  is  soumd,  and  that 
implementation  adheres  to  program  schedule  and  cost  goals •" 

Congress  tasked  the  Office  of  the  Secretary  of  Defense  to 
establish  a  firm  set  of  criteria  for  determimiag  the  conditions 
under  which  previously  delegated  management  oversight  authority 
iould  be  withdrawn.  These  criteria  are  enclosed.  They  will 
be  used  to  evaluate  both  program  stability  and  the 
effectiveness  of  the  oversight.  In  addition,  it  should  be 
recognised  that  OSD  will  maintain  the  prerogative  to  conduct 
In-Process-Review(s)  on  selected  programs  while  the  Service  or 
Agency  continues  its  oversight. 


Please  take  immediate  steps  to  communicate  these  criteria 
to  the  appropriate  organisations  and  program  managers. 


Enclosure 


CRITERIA  USED  JO  SUPPORT  DECISIONS  ON  WITHDRAWAL  OF 
DELEGATED  OVERSIGHT  AUTHORITY 


The  criteria  listed  below  are  not  intended  to  automatically 
result  in  a  withdrawal  of  delegated  oversight  authority. 

Rather,  a  breach  of  the  criteria  will  cause  an  OSD  staff  review 
of  the  relevant  facts  for  each  criteria  area  and  the  overall 
program  situation.  The  staff  findings  will  be  shared  with  the 
relevant  DoD  Component  and  forwarded  to  the  principals  of  the 
Major  Automated  Information  System  Review  Council  (MAISRC)  for  a 
decision  on  whether  or  not  to  withdraw  the  delegation. 


1.  Program  cost  growth  of  2St  or  more  has  developed  for  the 
overall  program. 

2.  Program  schedule  slippage  of  six  months  or  more  has  developed 
for  the  overall  program. 

S.  The  headquarters  executive  level  review  process,  as  required 
by  DoDD  7920.1,  has  not  been  adequate. 

4.  Available  program  funding  is  significantly  below  approved 
program  requirements,  making  the  approved  program 
uaexecutable. 

5.  Significant  problems  develop  in  the  execution  of  the 
acquisition  strategy  and  associated  procurement  actions. 

0.  Program  planning  or  execution  is  in  conflict  with  established 
DoD  policy. 

7.  Other  significant  issues  have  developed  which  remain 

unresolved  and  which  jeopardize  the  success  of  the  program. 


APPENDIX  F 

DESIGNATION  OF  PRINCIPALS  FOR  MAISRC  DECISION  MEETINGS 


ASSISTANT  SECRETARY  OF  DEFENSE 
WASHINGTON.  D  C.  20301 

9  NOV  1384 


MEMORANDUM  FOR  SECRETARIES  OF  THE  MILITARY  DEPARTMENTS 

UNDER  SECRETARIES  OF  DEFENSE 
ASSISTANT  SECRETARIES  OF  DEFENSE 

* 

SUBJECT:  Designation  of  Principals  for  Major  Automated 
Information  Systems  Review  Council  (MAISRC) 
Decision  Meetings 


This  memorandum  responds  to  questions  which  have  arisen  on 
the  designation  of  voting  principals  for  MAISRC  decision 
meetings.  Inasmuch  as  automated  information  systems  play  a 
vital  role  in  satisfying  our  mission  requirements,  active 
participation  by  the  Military  Departments  in  the  MAISRC 
decision  process  is  essential  to  insure  that  these  systems  meet 
the  needs  for  which  they  are  being  developed. 


A  Secretary  of  a  Military  Department  may  designate  a 
senior  official,  preferably  no  lower  than  Assistant  Secretary, 
as  a  principal  voting  member  when  a  program  from  that  Service 
is  before  the  MAISRC.  This  approach  is  consistent  with  that 
-currently  being  used  by  the  Defense  Systems  Acquisition  Review 
Council  (DSARC)  and  provides  for  increased  participation  by  the 
Military  Departments  in  the  DoD's  key  decision  processes*. 

If  you  have  any  questions  regarding  this  natter,  please 
contact  Mr.  Harry  E.  Pontius  on  697-6954. 


UT. 

• 

Robert  W.  Helm 
Assistant  Secretary  of  Defense 
(Comptroller) 
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INDEPENDENT  REVIEWS  TO  SUPPORT  THE  MAISRC  REVIEWS 


COMPTROLLER 


ASSISTANT  SECRETARY  OF  DEFENSE 


WASHINGTON.  O.C.  20301 

83  juk  1386 


MEMORANDUM  FOR  UNDER  SECRETARIES  OF  DEFENSE 

ASSISTANT  SECRETARIES  OF  DEFENSE 
ASSISTANT  SECRETARIES  OF  THE  MILITARY 
DEPARTMENTS  (FM) 

DIRECTORS  OF  DEFENSE  AGENCIES 


SUBJECT:  Independent  Reviews  to  Support  the  Major  Automated 
Information  System  Review  Council  (MAISRC)  Reviews 


In  early  November  of  1985 ,  I  met  with  the  Assistant 
Secretaries  of  the  Military  Departments  (FM)  and  we  reached  a 
consensus  to  implement  six  initiatives  that  would  strengthen 
general  purpose  ADP  acquisitions.  The  majority  of  the 
Initiatives  focus  on  supporting  the  program  managers,  but  one 
initiative  is  aimed  at  strengthening  the  OSD  MAISRC  by 
incorporating  the  Directors  of  Program  Analysis  and  Evaluation 
(DPAftE)  and  Operational  Test  and  Evaluation  (D0T5E)  into  the 
review  process.  Copies  of  memorandums  of  agreement  for  their 
participation  in  MAISRC  reviews  are  attached. 

The  attached  agreements  should  strengthen  (1)  cost  and 
benefits  analysis  and  (2)  test  and  evaluation  planning  and 
execution  for  major  automated  information  systems  that  require 
MAISRC  milestone  approval  at  the  OSD  level.  These  agreements 
supplement  existing  life  cycle  management  policies  until  such 
time  as  those  policies  are  updated. 

My  staff  will  work  closely  with  the  DoD  Components,  having 
major  systems  that  are  subject  to  an  OSD  MAISRC,  to  ensure  that 
these  agreements  are  implemented  into  the  MAISRC  process  as 
rapidly  and  effectively  as  possible.  Please  designate  a  point  } 
of  contact  who  will  work  with  Mr.  Ben  Ritt  of  my  staff  on  this 
transition.  Mr.  Ritt  can  be  contacted  at  697*9068. 


Enclosures  -  2 


(Comptroller) 


MEMORANDUM  OF  AGREEMENT 

PA&E  INVOLVEMENT  IN  THE  MAISRC  PROCESS 

A.  PURPOSE.  This  MOA  describes  the  roles  and  responsibilities 
that  Program  Analysis  and  Evaluation  (PA&E)  will  assume  in  the 
life  cycle  management  of  major  automated  information  systems 
through  participation  in  the  Major  Automated  Information  System 
Review  Council  (MAISRC)  process. 

B.  OBJECTIVES.  Involvement  of  PA&E  in  the  MAISRC  process  will 
seek  to  strengthen  the  cost  and  benefit  analyses  at  MAISRC 
reviews  by  ensuring  that: 

1.  Cost  and  benefit  estimates  are  adequate  at  each 
stage  in  the  development  of  a  major  AIS,  and  program 
planning  issues  are  resolved  as  early  as  possible. 

2.  The  arrangements  made  to  provide  cost  and  benefit 
estimates  are  capable  of  providing  objective  and  timely 
products. 

C.  BACKGROUND. 

The  life  cycle  management  process  uses  a  sequence  of  key 
decision  milestones  at  which  ADP  program  advancement  is  approved 
or  disapproved.  The  significant  elements  of  life  cycle 
management  are  early  planning,  executive  oversight,  early 
determination  of -costs,  and  accountability. 

A  number  of  program  cost  problems  and  issues  were  coming  to 
the  MAISRC  which  should  have  been  resolved  earlier.  Late 
detection  of  these  problems  interrupts  program  progress. 

Consequently,  a  policy  analysis  was  initiated  to  determine 
the  source  of  these  problems.  The  goal  was  to  Identify  actions 
to  strengthen  the  management  of  programs  and  accelerate  the 
overall  acquisition.  Durint  the  course  of  analysis,  the  IRMS 
staff  worked  closely  with  the  ADP  program  managers  and  the 
Military  Department  staffs  in  defining  problems  and  developing 
proposed  solutions. 

The  ASD(C)  approved  a  series  of  six  major  initiatives  to 
strengthen  certain  aspects  of  ADP  acquisitions.  The  program  of 
initiatives  has  two  major  goals:  accelerating  ADP  acquisitions 
and  ensuring  a  firm  management  base  for  each  program. 

o  Five  of  the  six  major  initiatives  are  focused  on 
support  of  the  program  manager  in  the  execution  of  his 
responsibilities. 

o  The  sixth  is  focused  on  strengthening  certain  aspects 
of  the  MAISRC  activities  by  including  PA&E  in  the  MAISRC 
process.  This  participation  is  expected  to  help  the 
MAISRC  avoid  past  problems  associated  with  cost  and 
benefits  Information. 


D.  MAI SRC  ACTIVITIES  AND  RESPONSIBILITIES  FOR  PASE. 

1.  The  Director.  PA6E  will  be  a  Principal  member  of  the 
MAISRC.  For  all  MAISRC's  this  PASE  membership  entails: 

a.  Cost  Analysis.  . PASE  will  provide  a  critical  review 
of  cost  estimates. 

b.  Benefits  Analysis.  When  the  MAISRC  chairman  does 
not  designate  some  other  organization  for  benefit 
analysis,  PAGE  will  provide  an  action  officer  to  review 
benefits  and  cost/benefit  analyses. 

c.  Review  Documentation.  PA|E  will  provide  staff 
reviews  for  the  incoming  System  Decision  Paper  and  for 
the  outgoing  System  Decision  Memorandum. 

2.  PASE  Involvement  at  specific  milestones  will  be: 

a.  At  Milestone  0  (Mission  Element  Need  Statement),  to 
provide  the  MAISRC  with  a  written  assessment  of  whatever 
cost  and  benefit  data  are  submitted  at  this  milestone. 

b.  At  Milestone  I  (Concept  Development),  to  provide  to 
the  MAISRC  a  written  assessment  of: 

o  The  validity  of  the  resource  investment  and 
benefits  estimates  for  the  selected  alternatives, 
and  of  their  consistency  with  any  stated 
constraints. 

o  The  adequacy  of  estimates  of  costs  for  training, 
logistical  support,  and  operational  test  and 
evaluation. 

c.  At  Milestone  II  (Definition  and  Design),  to  provide 
to  the  MAISRC  a  written  critical  review  of: 

o  The  economic  analysis  prepared  by  the  program 
manager  and/or  an  independent  agent. 

o  The  life  cycle  cost  estimates  for  the  system. 

d.  At  Milestone  III  (System  Development),  to  provide 
to  the  MAISRC  a  written  assessment  of  the  degree  to 
which: 

o  The  system  is  cost-effective  and  affordable  and 
remains  the  best  alternative. 

o  Trade-offs  have  been  made  to  balance  cost, 
schedule,  and  performance  effectively. 
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o  Life  cycle  cost  and  budget  estimates  are 
realistic  and  acceptable. 

3.  DoD  Component  program  managers  will  be  required  to 
present  cost  estimates  and  benefits  analyses  in  accordance  with 
the  attached  annex. 

E.  DURATION.  This  Agreement  will  be  in  force  until  July  lf 
1988,  unless  the  MAISRC  Principals  mutually  agree  that  a 
revision  is  necessary  or  until  there  is  a  modification  in  Life 
Cycle  Management  policy  and  these  roles  are  incorporated  into 
that  revised  policy. 


Approved: 


7 ROBERT  W.  HELM 
fsistant  Secretary  of  Defense 
(Comptroller) 


Date: 


O.CA*u _ 

DAVID  S.  C.  CHU 
Director,  Program  Analysis 
and  Evaluation 

Date:  ^ ^ 


Annex 

Procedures  for  Presentations 
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PREPARATION  AND  PRESENTATION 
OF  MAJOR  AIS  COST  ANALYSES  AND  BENEFITS  ANALYSES 

A.  OBJECTIVE  AND  ORGANIZATIONAL  RESPONSIBILITY 

1.  The  basic  objective  of  the  DoD  Component  presentations 
to  the  PA$E  cost  and  benefits  analysts  is  to  explain  in  detail 
how  the  independent  and  program  office  estimates  of  costs  and 
benefits  were  prepared.  This  will  permit  the  analysts  to  give 
the  MAISRC  an  assessment  of  the  benefits  the  AIS  is  expected  to 
provide*  and  of  its  cost,  and  of  the  methods  used  to  forecast 
those  benefits  and  costs. 

2.  Independent  cost  and  benefit  analyses  should  be 
prepared  by  an  organization  separate  from  the  control  and 
direction  of  the  program  or  project  office  that  is  directly 
responsible  for  the  acquisition  of  the  system  being  reviewed. 

B.  SCOPE  OF  INDEPENDENT  ANALYSIS 

1.  An  independent  cost  analysis  should  be  prepared  for 
each  alternative  that  will  be  presented  to  the  MAISRC.  A 
complete  description  of  these  alternatives  should  be  provided  as 
part  of  the  backup  documentation. 

2.  The  independent  analysis  should  provide  a  projection 
for  all  elements  of  life  cycle  costs  to  include  resource 
investment  and  the  costs  of  training,  logistical  support,  and, 
when  appropriate,  operating  costs. 

3.  When  program  alternatives  have  different  useful 
operational  lives,  the  costs  should  be  expressed  as  an 
equivalent  annual  cost  or  put  into  some  other  comparable  form. 

4.  The  independent  cost  analysis  should  separately  show 
both  prior  year  expenditures  and  projected  costs  by  cost 
element. 

C.  ANALYTIC  METHODS 


1.  The  rationale  and  procedures  used  to  make  independent 
cost  estimates  shall  be  explained  fully. 

a.  When  analogy  sizing/costing  techniques  are  used, 
the  methods  by  which  cost  information  was  acquired  and  adjusted 
are  to  be  documented.  If  the  adjustments  involved  judgments,  as 
in  the  use  of  complexity  factors,  the  basis  for  the  judgments, 
including  the  backgrounds  of  the  persons  making  them,  are  to  be 
presented. 

b.  When  standard  or  commercial  estimating  products 
are  used,  the  means  of  developing  inputs  to  those  products, 
including  the  backgrounds  of  the  persons  who  made  any 
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qualitative  ratings  used  as  inputs,  will  be  presented,  and  the 
inputs  themselves  will  be  presented  fully. 

c.  When  cost  estimation  relationships  are  used,  their 
specific  forms,  statistical  characteristics,  calibrating 
databases,  and  the  assumptions  used  to  apply  them  will  be 
presented  fully. 

2.  Quantification  of  uncertainty  by  the  use  of  probabil  ity 
distributions  on  cost  or  schedule  is  strongly  encouraged,  as  is 
the  use  of  interval  estimates.  The  probability  distributions 
and  methods  used  to  prepare  interval  estimates  should  be 
provided. 


3.  The  sensitivities  of  projected  costs  to  critical 
assumptions  should  be  examined  and  the  results  presented  to  the 
cost  analyst. 

D.  PRESENTATION  OF  COST  RESULTS 


1.  A  brief  overview  of  the  program  to  include  a 
description  of  the  undertaking,  the  hardware  and  software 
involved,  program  status,  procurement  strategy  (such  as, 
contracting  approach,  and  production  schedules)  should  be 
presented. 

2.  A  brief  description  of  each  alternative  to  be  presented 
at  the  MAISRC  should  be  discussed,  with  the  preferred 
alternative  highlighted. 

3.  The  Program  Manager  or  representative  should  present 
estimates  for  each  alternative  under  consideration  and  explain 
how  they  were  derived. 

4.  The  independent  cost  estimates  for  each  alternative 

should  be  presented,  with  an  explanation  of  how  they  were 

derived.  The  independent  estimates  will  be  compared  with  the 

Program  Manager's  estimate  by  cost  category,  and  significant 
differences  examined  in  detail. 

5.  The  investment  estimates  should  be  shown  in  both 

constant  and  current  dollars.  Operating  and  support  costs 

estimates  should  be  shown  in  constant  dollars.  The  constant 
dollars  should  be  as  close  as  possible  to  the  present  budget 
year. 


6.  For  purposes  of  comparing  independent  estimates  with 
the  Program  Manager's  estimates,  the  same  assumptions,  such  as, 
funding  schedule,  delivery  schedule,  escalation,* and  outlay 
rates  should  be  used.  If  the  independent  analysis  team  does  not 
believe  the  Program  Manager's  assumptions  are  valid,  this  fact 
should  be  identified  and  its  impact  calculated. 
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7.  If  the  Program  Manager's  estimate  is  validated  and 
found  to  be  reasonable,  the  basis  for  reaching  this  conclusion 
must  be  presented. 

E.  PROCEDURES  FOR  PRESENTING  A  COST  ESTIMATE 


1.  Briefing  of  cost  estimates  will  generally  adhere  to  the 
following  time  schedule  unless  other  arrangements  are  made  with 
the  cost  analyst: 

a.  Within  25  working  days  prior  to  a  MA1SRC  milestone 
review,  the  PASE  cost  analyst  will  meet  with  the  DoD  Component 
representatives  and  agree  on  the  agenda  for  a  presentation  of 
the  cost  estimates. 

b.  At  least  2D  working  days  prior  to  the  MAISRC,  the 
DoD  Component  shall  provide  the  PA&E  cost  analyst  on  an  informal 
basis,  two  copies  of  the  information  and  analysis  that  will  be 
used  as  the  basis  for  the  cost  briefing. 

c.  At  least  15  working  days  prior  to  a  MAISRC  milestone 
review,  the  formal  presentation  of  the  DoD  Component's 
independent  cost  analysis  and  program  office  estimates  shall  be 
made.  Copies  of  the  briefing  charts,  the  briefing  text  (if  one 
is  used)  and  a  summary  report  of  the  estimates  shall  be  made 
available  at  the  time  of  presentation. 

3.  The  specific  assumptions  and  calculations  used  to 
derive  the  independent  and  the  Program  Manager's  cost  estimate 
for  each  alternative  are  to  be  made  available. 

4.  The  DoD  Component's  organization  staffs  preparing  the 
cost  analyses  shall  maintain  a  close  liaison  with  the  PASE  cost 
analyst  during  the  review  process  to  ensure  full  understanding 
of  the  DoD  Component  estimates. 

5.  PAftE's  final  cost  report  to  the  MAISRC  will  be  made 
available  to  the  appropriate  DoD  Components  at  the  time  it  is 
sent  to  the  MAISRC.  Appropriate  PA|E  staff  will  be  available  to 
discuss  its  analysis  and  conclusions  fully  at  that  time. 

F.  PROCEDURES  FOR  A  BENEFITS  ANALYSIS  PRESENTATION 

1.  At  least  2S  working  days  prior  to  a  MAISRC  milestone 
review,  the  benefits  analyst  will  meet  with  DoD  Component 
representatives  and  agree  on  the  agenda  for  presentation  of 
expected  benefits.  This  meeting  may  coincide  with- the  meeting 
to  set  the  agenda  for  presenting  cost  estimates,  described  in 
paragraph  E  above.  With  the  agreement  of  the  cost  analyst 
representative,  the  benefits  analyst  say  require  a  presentation 
of  benefits  to  be  integrated  with  the  presentation  of  cost 
estimates. 
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•3. 


< 

* 

1 

2.  In  all  cases,  the  DoD  Component  will  provide  the 
benefits  analyst  with  an  appropriate  point-of-contact  to  discuss 
benefit  estimates  at  the  several  milestones  as  follows:  ; 

( 

At  Milestone  0:  to  discuss  the  mission  deficiency  that  is  to  j 

be  presented  to  the  MENS,  as  well  as  any  estimated  benefits 
that  will  be  used  in  the  MENS  to  justify  exploring  automated 
information  systems  to  remedy  the  deficiency; 

At  Milestone  I:  to  discuss  the  cost-benefit  analysis  in  the 
Resources  Annex  of  the  System  Decision  Paper  (DoD  Instruction 
7920.2,  Enclosure  1,  Paragraph  B.2.e); 

At  Milestone  II:  to  discuss  the  economic  analysis  required 
by  DoDI  7920.2,  Enclosure  2,  Paragraph  C.2.b,  as  well  as 
updates  to  the  Resources  Annex  of  the  System  Decision  Paper; 

At  Milestone  III:  to  discuss  the  DoD  Component's  most  recent 
benefits  estimates,  as  reflected  in  updates  to  the  system's 
economic  analysis  and  to  the  Resources  Annex  of  the  System 
Decision  Paper. 
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MEMORANDUM  OF  AGREEMENT 

DOT&E  INVOLVEMENT  IN  THE  MAISRC  PROCESS 


A.  PURPOSE .  This  MOA  describes  the  roles  and  responsibilities 
which  Operational  Test  and  Evaluation  (0T$E)  will  assume  as  part 
of  the  Life  Cycle  Management  of  Major  Automation  Information 
Systems  through  the  Major  Automated  Information  System  Review 
Council  (MAISRC)  process. 

B.  OBJECTIVES.  DOT§£  involvement  in  the  MAISRC  is  intended  to 
strengthen  the  test  and  evaluation  aspects  of  MAISRC  reviews  by 
ensuring  that: 


1.  Test  and  evaluation  management  structures  support 
independent  and  objective  test  and  evaluation 
activities. 

2.  Early  test  planning  is  adequate  and  helps  to  resolve 
early  program  planning  issues. 

3.  Test  execution  and  evaluation  reports  provide 
meaningful  assessments  of  the  program  status. 

C.  BACKGROUND. 

The  move  to  incorporate  the  DOT$E  organization  into  the 
MAISRC  process  grew  out  of  the  ADP  Acquisition  Improvement 
Analysis  directed  by  the  ASD(C)  in  the  spring  of  198S.  The 
analysis  was  prompted  by  the  fact  that  the  ASD(C)  perceived  that 
there  were  a  number  of  problems  which  were  coming  to  the  MAISRC 
which  could  have,  and  should  have,  been  resolved  earlier. 

As  a  result  of  that  analysis  effort,  several  important 
comclpsions  were  reached.  Probably  the  most  important 
conclusion  was  that  delays  in  acquisition  appqar  more  related  to 
the  program  management  staff's  lack  of  experience  or 
difficulties  in  completing  certain  needed  tasks  successfully 
than  to  perceived  problems  with  the  acquisition  process  itself. 

The  ASD(C)  approved  a  series  of  six  major  initiatives  to 
strengthen  certain  aspects  of  ADP  acquisitions.  The  program  of 
initiatives  has  two  major  goals:  accelerating  ADP  acquisitions 
and  ensuring  a  firm  management  base  for  each  program. 

o  Five  of  the  six  major  initiatives  are  focused  on 
support  of  the  program  manager  in  the  execution  of  his 
responsibilities. 


a  The  sixth  is  focused  on  strengthening  certain  aspects 
of  the  MAISRC  activities.  The  initiative  to  include 


DOT |E  in  the  MAI SKC  process  it  part  of’  this  last 
initiative  area.  Through  incorporation  of  DOTH  it  i» 
anticipated  that  certain  past  problems  associated  with 
incomplete  testing  information  or  other  problems  with 
test  planning  and  execution  will  be  avoided. 


The  following  represent  the  basic  activities  and 
responsibilities.  The  specific  degree  and  form  of  involvement 
will  be  dependent  on  the  needs  of  a  particular  program. 

1.  FOR  ALL  MAI  SRC1  s 


a.  Be  a  Principal  member  of  the  MA1SRC. 

b.  Provide  staff  review  and  processing  support  for  the 
incoming  System  Decision  Paper  and  for  the  outgoing 
System  Decision  Memorandum. 

2.  WHEN  A  PROGRAM  HAS  SIGNIFICANT  OPERATIONAL  TUT  AND 
EVALUATION 


At  Milestone  0  and,  in  some  cases,  at  Milestone  I, 

DOT |E  will  review  the  operational  nature  of  the  AIS 
being  procured  and  will  determine  if  DOTH  oversight 
of  the  AIS  operational  test  and  evaluation  (OTU) 
program  is  required.  When  DOTH  oversight  is 
required,  the  System  Decision  Memorandum  or  Mission 
Element  Need  Statement  approval  will  so  state  and. will 
direct  the  preparation  of  a  Test  and  Bvaluatlon  Master 
Plan  (TEMP)  following  the  appropriate  guidelines  of 
the  TEMP  Procedures  Manual  (DoD  S000.3  M-l).  DOTH 
will  then  assume  a  leadership  role  in  the  review  of 
operational  test  planning,  test  execution  and  test 
results  assessment  and  will  specifically: 

-  Approve  the  Test  and  Evaluation  Master  Plan 
(TEMP)  that  is  developed  for  Milestone  I. 

-  Approve  the  test  and  evaluation  organizational 
structure  of  the  group  assigned  to  plan,  conduct 
and  report  on  the  operational  test  and 
evaluation. 


-  Approve  operational  test  plan  adequacy  prior  to 
test  commencement. 


Observe  testing  as  required. 


Provide  a  formal  assessment  to  the  MAISRC  as  well 
as  any  reports  to  the  SecDef  or- others  that  may 
be  necessary. 

3.  DOT IE  will  assume  its  basic  responsibilities  in  the  Major 
Automated  Information  System  Review  Council  within  existing 
resources.  When  "full"  DOTIE  involvement  is  required  on  a 
program,  then  temporary  additional  staffing  will  be  needed  with, 
a  user  or  "operator"  from  the  mission  or  business  area  which  the 
system  will  support. 

E.  DURATION.  This  Agreement  will  remain  in  force  until  its 
provisions  are  incorporated  into  DoDD  7920.1  and  DoDI  7920.2. 


Approved : 


(Comptroller) 


Dete:  .&*n±',.*** 


Page  3  of  3 


APPENDIX  H 


ADP  ACQUISITION  IMPROVEMENTS  PROGRAM 


ADP  ACQUISmON  IMPROVEMENTS  PROGRAM 


H.l  INTRODUCTION 

Recently,  the  Office  of  the  Secretary  of  Defense  (OSD)  conducted  a  study  to  look  into 
the  Automatic  Data  Processing  (ADP)  management  process  and  identify  policy  areas  that 
require  adjustments  to  accelerate  acquisitions  and,  at  the  same  time,  ensure  a  firm 
management  base  for  the  development  of  the  program.  Previously,  delays  in  major 
acquisitions  were  occurring  because  issues  were  not  being  identified  and  resolved  early  in 
the  development  cycle.  Examples  of  these  unresolved  issues  were: 

•  Acquisition  strategy  inappropriately  limited  competition; 

•  Key  alternatives  to  technical  architecture/acquisition  strategy  had  not  been 
evaluated;  and 

•  Testing  was  not  completed  prior  to  deployment. 

The  Department  of  Defense  (DoD)  study  found  that  Life  Cycle  Management  (LCM) 
policies  cover  the  areas  in  question,  but  a  certain  amount  of  confusion  resulted  from 
misinterpretation  of  DoD  policies.  Causes  for  this  confusion  were  due  to  the  complexity 
of  the  concepts  and  issues  surrounding  the  development  of  the  functional  concept/ 
technical  architecture,  acquisition  strategy  and  risk  assessment,  combined  with  the 
relative  inexperience  and  training  of  the  Program  Managers  (PM).  Funner,  problems  were 
encountered  in  understanding  the  status  of  testing  and  the  stability  of  costs  and  schedules. 
Lastly,  difficulties  were  encountered  in  specific  planning  products  (e  g.,  Mission  Element 
Need  Statement  (MENS),  acquisition  strategy)  because  the  contents  and  form  were 
unclear  to  the  OSD. 

On  the  basis  of  these  findings,  DoD  concluded  that: 

•  Difficulties  reside  in  specific  program  areas  rather  than  with  the  LCM  process 
itself; 

•  Inadequate  experience/education  of  the  management  staff  contribute  to  the  prob¬ 
lems  and  delays;  and 

•  Assistance/support  must  be  provided  to  the  management  team  if  goals  are  to  be 
achieved. 

Accordingly.  OSD  developed  several  management  improvement  initiatives  to 
strengthen  the  quality  and  timeliness  of  major  ADP  acquisitions  Five  of  these  initiatives 
focused  on  supporting  the  PM  and  staff,  while  one  initiative  was  targeted  to  assist  the 
Major  Automated  Information  System  Review  Council  (MAJSRC) 


H.2  THE  PROGRAM  MANAGEMENT  INITIATIVES 


The  first  initiative  was  accomplished  in  November  198S,  and  consisted  of  providing 
die  Services  with  copies  of  three  quality  System  Decision  Papers  (SDP)  that  might  be  used 
as  references.  These  examples,  used  in  conjunction  with  DoDD  7920.1  and  DoDi  7920.2 
(the  primary  guides  for  MAISRC  documentation)  should  assist  the  PM  and  staff  in  the 
preparation  of  their  products. 

The  second  initiative  will  provide  for  the  establishment  of  a  firm  management 
baseline  for  the  program  that  will  increase  the  accuracy  of  program  cost  and  schedule 
planning.  The  initiative  will  also  facilitate  clear  assessments  of  cost,  schedule,  or 
capability  adjustments.  A  draft  DoD  directive  has  been  reviewed  by  the  military 
departments  and  will  be  published  in  1987. 

The  third  initiative  was  enacted  in  November  1986,  and  establishes  a  talented  and 
independent  group  that  would  be  available,  as  needed,  to  the  PMs  to  advise  on  key 
program  challenges.  This  group  will  provide  its  confidential  findings  directly  to  the  PM 
and  will  not  provide  information  to  the  MAISRC.  The  Air  Force  acts  as  Executive  Agent 
for  this  initiative. 

The  fourth  initiative  consists  of  strengthening  the  education  and  experience  of  the 
PM’s  office.  The  DoD  is  working  through  the  Services  to  specify  essential  curriculum  for 
education  as  well  as  developing  options  to  strengthen  experience  requirements.  The 
Department  of  Defense  Computer  Institute  is  currently  developing  a  syllabus  and  plans  to 
inaugurate  a  new  course  in  fiscal  year  1987.  Additionally,  a  Joint  Program  Managers' 
forum  has  been  established  and  provides  the  various  managers  with  a  setting  to  air  and 
discuss  items  of  mutual  concern. 

The  fifth,  and  last,  initiative  currently  being  developed  for  the  PM  is  an  amplification 
of  policy  guidance.  Specifically,  DoD  will  clarify  what  analysis  or  products  must  be 
developed  to  support  program  planning,  decisions,  and  actions. 

H.3  THE  MAISRC  INITIATIVE 

The  sixth  initiative  developed  by  the  the  DoD,  and  the  only  one  not  designed  for  the 
PM,  will  support  the  MAISRC.  This  initiative  provides  for  strengthened  independent 
review  and  assessment  support  to  the  MAISRC  Principals.  This  initiative  incorporates  the 
Directors  of  Program  Analysis  and  Evaluation  (DPAAE)  and  Operational  Test  and 
Evaluation  (DOTAE)  into  the  review  process  as  Principals  on  the  MAISRC  Cost  and 
benefit  analysis  as  well  as  test  and  evaluation  planning  and  execution  should  be  greatly 
improved  and  thereby  strengthen  the  development  process  (See  Appendix  G  ) 


ASSISTANT  SECRETARY  OF  DEFENSE 
WASHINGTON,  DC  10S0I-1100 

I  •  MOV  UK 


MEMORANDUM  FOR  ASSISTANT  SECRETARY  OF  ARMY  (FM) 
ASSISTANT  SECRETARY  OF  NAVY  (FM) 
DIRECTOR,  DEFENSE  LOGISTICS  AGENCY 

SUBJECT:  Independent  Assistance  Group 


You  will  recall  that  one  of  the  identified  ADP  acquisition 
inprovenent  initiatives  was  the  establishaent  of  an  independent 
assistance  group  to  provide  direct  support  to  progran  nanagers. 
The  Air  Force,  as  executive  agent  for  this  effort,  has 
completed  its  charter  and  I  have  approved  it.  Further,  initial 
funds  of  $1,000,000  in  0|N  have  been  provided  to  support 
efforts  through  FY  S7. 

I  encourage  you  to  nake  direct  contact  with  the  Air  Force 
to  sake  plans  to  utilize  these  resources  as  early  as  possible. 


(OoapnraZw) 


cc:  Assistant  Secretry  of  Air  Force  (FM) 


CHARTER  FOR  TBR 


TRDRFKMDKNT  ASSISTANCE  GROUP 


a.  ymncig. 

1.  Manor an dux  by  the  Assistant  Secretary  of  Defense 
(Comptroller)  (ASD(C)),  23  Aug  85,  "Automated  Data  Processing 
(ADP)  Acquisition  Improvement.”  This  memorandum  provided  the 
results  of  a  study  by  the  Office  of  the  Assistant  Secretary 
of  Defense  (Comptroller)  (OASD(C))  for  improvement  of  the  ADP 
acquisition  process  in  the  Department  of  Defense  (DOD)  for 
major  automated  information  systems  (AIS)  programs. 

2.  Memorandum  by  the  ASD(C),  28  Feb  86,  "Executive  Agent  for 
the  Independent  Assistance  Group.”  This  memorandum  requested 
establishment  of  an  Executive  Agent,  which  is  included  in 
this  document. 

E.  PURPOSE.  The  Independent  Assistance  Group  (IAG) ,  one  of  the 
initiatives  recommended  by  the  23  Aug  85  ASD(C)  memoiandum, 
will  be  a  group  of  organisations  or  companies  (also  referred 
to  as  providers*  in  this  charter)  which  will  be  under 
contract  to  the  Department  of  the  Air  Force  in  its  capacity 
as  Executive  Agent.  The  IAG  will  provide  program  manage- 
ment  review  and  recommendations  to  managers  of  DOD  major 
AIS  programs  upon  request  from  the  managers.  This  charter 
establishes  the  IAG.  The  goal  of  the  IAG  is  to  assist  these 
program  managers  in  reducing  the  overall  risks  of  program 

*  As  used  in  this  charter,  this  term  means  both  comoiercial, 
for-profit  management  consulting  firms  and  not-for-profit 
government  or  academic  enterprises  qualifed  to  provide  the 

assistance. 


failure,  cost/budget  overruns,  noncompetitive  acquisition 
strategy,  technical  failure,  etc.  This  charter  also* 

1.  Designates  an  Executive  Agent  for  IAG  operations. 

2.  Establishes  a  DOD  Executive  Coonaittee  to  provide 
corporate  DOD  oversight  of  TAG  operations. 

3.  Defines  the  role  and  responsibilities  of  the  Executive 
Agent  and  the  Executive  Committee. 

4.  Identifies  the  objectives,  functions,  and  professional 
requirements  (desirable  skills,  knowledge,  and  experience) 
for  IAG  personnel. 

5.  Provides  the  basic  operating  guidelines  for  the  OASD(C) 

IAG  initiative. 

€.  Establishes  policies  for  funding  of  IAG  operations. 
DE8IGMATI0M  OF  THE  EXECUTIVE  AGEBT.  The  Department  of  the 
Air  Torce  is  hereby  designated  as  Executive  Agent  for  the 
IAG.  The  Air  Force  signatory  to  this  charter  is  hereby 
authorised  to  delegate  responsibility  for  the  initiation  of  the 
IAG  to  one  or  more  subordinate  Air  Force  elements. 

HOLE  AMD  KE8P0M8IBILITIE8  OF  THE  EXECOTIVE  AGEET.  As  Execu¬ 
tive  Agent  for  the  IAG,  the  Department  of  the  Air  Force  shall 
act  for  OASD(C)  in  all  matters  pertaining  to  IAG  operations. 
These  matters  include,  but  are  not  limited  tot 
1.  Recruiting  and  staffing  a  cadre  of  personnel  within  the 
Air  Force  to  oversee  the  operation  of  the  IAG. 


2.  Development  of  criteria  for  the  competitive  selection  of 
qualified  providers  who  will  constitute  the  IAG  and  who  will 
be  used  selectively  to  render  independent  program  management 
assistance  to  major  AIS  program  managers  in  DOD . 

3.  Selection  of  responsive,  qualified  IAG  providers. 

4.  Annual  review  and  update/modification,  as  required,  of 
this  charter. 

5.  Acting  as  the  single  DOD  point  of  contact  for  inquiries 
regarding  the  IAG  or  its  activities. 

6.  Staffing  requests  from  defense  agencies  for  IAG 

assistance. 

7.  Providing  administrative  support  to  the  Executive 
Committee. 

8.  Completion  of  such  actions  pertaining  to  the  IAG 
initiative  as  may  be  tasked  by  GASD(C). 

B.  THE  EXECUTIVE  COMMITTEE.  An  Executive  Committee  shall  be 
formed  of  one  senior  official  of  each  service,  in  the  grade 
of  0-7  or  equivalent,  to  review  DOD  program  manager  requests 
for  use  of  the  IAG.  The  Executive  Committee  may  also  include 
senior  officials  from  the  major  defense  agencies  as  approved 
by  OASD(C).  The  chair  of  the  Executive  Committee  shall  be 
rotated  at  the  beginning  of  each  fiscal  year  in  the  following 
order i  Air  Force,  Army,  and  Navy,  and  defense  agencies  as 
approved  by  OASD(C).  The  Executive  Committee  shall  meet  at 
the  call  of  the  chair  to  review  requests  for  IAG  services, 
and  shall  specifically  authorize  the  provision  of  services  by 
the  IAG  to  satisfy  each  request. 


FOMCTIOH,  PROCBDORBS.  AND  PROFESSIONAL  REQOIREMENTS . 

1.  IAG  FUNCTION.  The  function  of  the  IAG  is  to  assist  the 
manager  of  a  DOD  major  AIS  program  (upon  written  request  and 
Executive  Committee  approval)  in  preparing  for  key  milestone 
reviews  and/or  assessing  substantive  program  issues  affecting 
the  program's  development ,  completion,  cost,  etc. 

2.  IAG  PROCBDORBS.  Each  request  for  IAG  assistance  will 
be  initiated  by  the  program  manager  and  clearly  state  the 
milestone  review(s)  needing  IAG  support  and/or  the  program 
issue(s)  requiring  assessment.  All  IAG  products  or  deliver¬ 
ables  shall  be  provided  directly  by  the  providers  to  the 
program  manager  requesting  the  assistance.  Desired  IAG 
products  or  deliverables  shall  be  agreed  upon  by  the 
providers  and  the  program  manager,  and  be  approved  by  the 
Executive  Committee,  prior  to  any  provider  effort  on  behalf 
of  the  program  manager.  This  agreement  shall  be  in  the  form 
of  a  statement  of  work  (SOW)  describing  the  desired  products 
or  deliverables.  The  SOW  will  becosie  effective  after  review 
and  approval  by  the  Executive  Committee  and  signature  by  the 
program  manager  and  the  providers.  These  products  or  deliv¬ 
erables  may  take  the  form  of  memoranda  of  opinion,  written 
reports  on  the  adequacy  of  the  program  strategy,  and  recom¬ 
mendations  for  corrective  action,  verbal  briefings,  or  other 
deliverables  as  mutually  agreed.  The  IAG  will  place  special 
emphasis  on  practical,  results-oriented  recommendations  or 
observations.  The  providers  will  not  perform  direct  program 
management.  Rather,  they  will  provide  objective,  independent 
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advice  to  program  managers  under  the  terms  of  the  statements 
of  work.  In  providing  support  to  program  managers,  providers 
may  perform  the  following  functions t 

a.  Determine  the  adequacy  of  the  range  of  alternative 
system  concepts  under  consideration  by  the  program  manager. 

b.  Evaluate  the  appropriateness  of  the  system  concept 
selected  for  the  major  AIS  program. 

c.  Identify  deficiencies,  gaps,  or  inconsistencies  in 
the  analyses  supporting  the  selection  of  the  system  concept. 

d.  Identify  errors  in  fact  that  can  influence  the  major 
AIS  program. 

e.  Identify  important  differences  in  judgment  and 
explain  their  significance. 

f.  Identify  apparent  and  critical  technical,  schedule, 
or  cost  risks  for  the  major  AIS  program,  and  recomewnd 
approaches  to  reduce  them. 

g.  Make  any  other  suggestions  as  necessary  to  strengthen 
the  major  AIS  program. 

3.  IAG  PROFESSIONAL  RBQPIREMEMTS .  The  success  of  the 
IAG  depends  greatly  on  the  skills,  knowledge,  and  experience 
of  the  personnel  employed  by  the  providers.  These  signifi¬ 
cant  and  essential  personnel  factors  are  listed  in  the 
attachment  to  this  charter. 

G.  SASIC  OPERATING  GO I DEL IKES  FOR  THE  IHDKPSHDEHT  ASSISTANCE 
GROPP  INITIATIVE. 

1.  POLICY  AND  BUDGETARY  DECISIONS.  The  OASD(C)  signatory  to 
this  charter  shall  be  the  single  responsible  official  for 


all  policy  and  budgetary  decision*  regarding  IAG  operation* 
as  defined  in  this  charter. 

2.  CONFLICTS  OF  INTEREST.  Given  the  potential  sensitivity 
of  the  subjects,  conceptual  alternatives,  and  policy  issues 
to  be  discussed  and  evaluated,  the  employees  of  providers 
must  be  free  fro*  actual,  potential,  or  apparent  conflicts  of 
interest.  A  provider  of  IAG  support  eust  gain  no  competitive 
advantage  from  the  role  of  supporting  a  major  AIS  program 
manager;  and  a  provider  should  not  lose  objectivity  as  a 
result  of  having  profit-seeking  consulting,  implementation, 
manufacturing,  or  other  conflicting  organisational  goals, 
such  a*  a  desire  to  service  other  commsrcial  clients. 

3.  START-OP  FUMDI1IG.  Start-up  funding  for  IAG  operations 
will  be  provided  by  OSD  in  the  amount  of  $1,000,000  for  FT 
1987.  During  FY  1987,  assistance  resource  requirements  in 
excess  of  these  amounts  will  be  satisfied  os  a  reimbursed 
basis  through  payment  by  each  major  AIS  program  receiving 
IAG  services. 

4.  FY  1988  AND  SUBSEQUENT  FUNDING.  Beginning  in  FY  1988, 
the  IAG  will  commence  operations  on  a  fully  reimbursed  basis 
through  payment  by  each  major  AIS  program  receiving  IAG  ser¬ 
vices. 

5.  ASSISTANCE  REQUEST  PRIORITIES.  Equal  consideration  will 
be  given  to  all  major  AIS  program  managers  in  DOD  regardless 
of  military  department  or  DOD  agency.  The  Executive  Committee 
will  attempt  to  resolve  questions  of  priorities  fairly  in 
recognition  of  the  actual  program  issues  involved.  The 


ASD(C)  will  resolve  prioritization  issues  that  cannot  be 
resolved  by  the  Executive  Committee. 

i.  USE  or  IAG  RESOURCES .  The  Executive  Committee  shall  take 
all  steps  necessary  to  ensure  efficient  use  of  IAG  resources 
and  funding.  All  relevant  facts,  analyses,  documentation, 
and  other  sources  of  information  shall  be  marshalled  and 
organized  by  the  major  AIS  program  manager  before  the  initial 
Interaction  with  an  IAG  provider. 

7.  CONFIDENTIALITY  OF  IAG  PRODUCTS  AND  DELIVERABLES.  The 
strict  confidentiality  of  each  IAG  report  or  other  deliv¬ 
erable  to  a  major  AIS  program  manager  shall  be  maintained  at 
all  times,  both  during  the  actual  performance  of  IAG  support 
to  the  program  and  after  such  support  ends.  Providers  shall 
certify,  in  writing,  their  freedom  from  actual,  potential,  or 
apparent  conflicts  of  interest  with  respect  to  that  major  AIS 
program.  IAG  reports  or  other  deliverables  will  not  be 
released  to  any  third  party  without  the  written  permission  of 
the  major  AIS  program  manager. 

8.  REPORTING  IAG  ACTIVITIES.  On  behalf  of  the  Executive 
Committee,  the  Executive  Agent  shall  provide  the  Assistant 
Secretaries  (Financial  Management)  of  the  Services  and  the 
ASD(C)  with  an  overall  report  of  the  activities  of  the  IAG  op 
a  semiannual  basis. 

9.  RESOLUTION  OF  MAJOR  ISSUES  OR  PROBLEMS.  Any  major  issues 
or  problems  in  IAG  operations  which  require  OASD(C)  involvemen 


•ball  be  communicated  through  the  Executive  Agent  to  the 
A8D(C) • 
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)BERT  B.  LU0MXG,  HR  I  GAMER  GENERAL,  USAP 
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ROBERT' M.  HELM 

Assistant  Secretary  of  Defense  (Comptroller) 
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Date 


ZA6  PROVIDER  PROFESSIONAL  REQUIREMENTS 

A.  Experience .  Provider  employee  experience  Is  considered 
essential  in  the  following  areas: 

1.  Design,  development,  and  evaluation  of  major  auto¬ 
mated  information  systems  (AISs).  This  should  include  the 
hardware,  software,  and  data  communications  aspects  of  these 
systems.  It  should  also  include  analysis/review  experience 
with  conceptual  system  approaches. 

2.  Implemention  of  diverse  functional  applications  on 
several  types  of  major  hardware/systems  software  architec¬ 
tures.  This  is  required  by  the  variety  of  computer  systems 
architectures  in  use  or  planned  for  use  within  DOD. 

B.  Knowledge .  The  following  are  considered  essential  areas 
of  broad  and  current  knowledge: 

1.  Commercial  products  and  applied  research  development 
in  computer  hardware,  systems  software,  and  data  communica¬ 
tions  technologies. 

2.  Approaches  used  in  both  government  and  the  private 
sector  to  develop  and  field  large,  major  automated  systems. 

3.  Proven  practices  and  procedures  for  major  AIS  program 
management  and  ADP  resources  acquisition. 

4.  Issues  and  problems  in  internal  management  controls, 
ADP  system  security,  and  privacy  of  personal  data. 

5.  Principles  and  practices  of  ADP  program  management 
and  life  cycle  management. 

6.  Principles  and  practices  associated  with  program 
integration. 
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C.  Skills.  The  following  are  considered  essential  skill 
requirements t 

1.  Very  quick  study  capability  with  strong  analytic  and 
conceptual  skills. 

2.  Very  strong  oral  and  written  skills  with  emphasis  on 
extremely  clear  idea  presentation. 

3.  Strong  abilities  to  sift  through  many  facts  and  draw 
out  the  central  issue  or  issues. 

4.  Demonstrated  capabilities  to  identify  specif ic, 
practical  actions  that  have  high  potential  for  resolving 
identified  MS  program  problems  and  for  reattaining  program 
momentum. 

5.  Strong  abilities  to  address  and  resolve  unstructured 
problems . 
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